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Internetwork  environments  are  inherently  vulnerable  to  security  threats  due  to 
their  openness,  the  nonexistence  of  a  centralized  management  authority,  and  insecure 
communication  channels.  Moreover,  increasing  internetwork  applications  frequently 
require  connecting  administrative  domains  with  competing  interests.  In  this  envi- 
ronment, unauthorized  access  to  network  resources  is  an  issue  of  growing  concern. 
However,  existing  resource  access  control  schemes  either  have  security  flaws  or  suffer 
from  inconvenience  and  inflexibihty. 

The  primary  objective  of  this  research  is  to  develop  a  secure  and  eflficient  in- 
ternetwork access  control  scheme.  Packet-level  access  security  scheme  (PASS)  is  a 
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policy  enforcement  mechanism  for  stub  domains.  In  using  PASS,  a  unique  pass-key 
is  assigned  to  each  communication  session  after  both  end-systems  are  authorized  and 
authenticated.  Any  valid  packet  should  include  a  proper  pass  in  it  to  be  verified 
by  access  control  gateways.  The  security  and  performance  of  this  protocol  has  been 
assessed  and  the  results  are  compared  with  those  of  other  schemes. 

PASS  uses  a  new  interdomain  authentication  protocol  that  utilizes  ITU-T  X.509 
directory  authentication  service  as  the  public  key  provider.  This  removes  an  unre- 
alistic assumption  about  the  availability  of  a  trusted  third  party  used  in  most  other 
existing  protocols.  The  authentication  goals  of  the  protocol  are  verified  by  using 
BAN  logic.  Two  variations  of  this  protocol  are  given  for  the  situations  that  require 
one-way  authentication  and  one-way  pass. 

To  complement  the  policy  enforcing  scheme,  a  secure  transit  control  mechanism 
is  proposed.  Controlling  access  to  network  resources  in  intermediate  domains  is 
closely  related  to  packet  routing.  Therefore,  two  policy-based  routing  protocols  are 
investigated  first  and  security  mechanisms  are  provided  to  the  Inter-Domain  Policy 
Routing  protocol  (IDPR).  The  cost  of  the  added  security  is  analyzed  for  several  modes 
of  transit  packet  verification. 

In  summary,  this  dissertation  is  devoted  to  the  investigation  of  three  main  issues 
in  internetwork  access  control.  First,  a  secure  and  efficient  stub  domain  access  control 
scheme  is  proposed.  Next,  a  new  interdomain  authentication  protocol  is  presented 
to  be  used  in  PASS.  Finally,  a  secure  transit  control  scheme  is  proposed  by  adding 
security  mechanisms  to  IDPR. 
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CHAPTER  1 
INTRODUCTION 

1.1    Computer  Security 

Computer  security  is  assuring  the  confidentiality,  integrity,  and  availability  of 
components  of  computing  systems.  The  three  principal  pieces  of  a  computing  system 
subject  to  attacks  are  hardware,  software,  and  data.  These  three  pieces,  and  the 
communications  between  them,  constitute  the  basis  of  computer  security  vulnerabil- 
ities. In  order  to  realize  the  computer  security,  a  secure  computer  system  needs  to 
provide  security  services  to  its  users. 

1.1.1  Objectives 

The  principal  objectives  of  computer  security  can  be  more  specifically  charac- 
terized as  the  protection  of  confidentiality,  integrity,  and  availability  of  computing 
system  components,  as  discussed  below. 

•  Protecting  data  confidentiality  means  preventing  unauthorized  accessing 
of  computing  system  assetts.  The  type  of  access  is  read-type  access  such  as 
reading,  viewing,  printing,  or  even  just  knowing  the  existence  of  an  object. 

•  Protecting  data  integrity  means  preventing  unauthorized  modification  of 
computing  system  assetts.  In  this  context,  modification  includes  writing,  chang- 
ing, changing  status,  deleting,  and  creating. 
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•  Protecting  data  availability  means  preventing  denial  of  service.  An  autho- 
rized user  should  not  be  prevented  from  accessing  those  objects  to  which  he  or 
she  or  it  has  a  legitimate  access  right. 

1.1.2    Security  Services 

To  achieve  these  computer  security  objectives,  a  secure  computer  system  needs 
to  provide  a  set  of  computer  security  services,  with  which  the  users  can  protect  their 
data  and  the  system  can  protect  its  resources  appropriately,  as  follows. 

•  Authentication  is  verifying  the  identity  of  a  user  or  a  process  on  behalf  of 
him.  In  simple  words,  an  authentication  service  tries  to  answer  the  question, 
who  are  you  ? 

•  Authorization  is  controlling  all  accesses  of  users  to  data,  according  to  some 
pre-determined  security  policies.  In  simple  words,  an  authorization  service  tries 
to  answer  the  question,  what  can  you  access  and  how  ? 

•  Auditing  is  recording  occurrences  of  all  security-relevant  events  in  an  audit 
log.  In  simple  words,  an  auditing  service  tries  to  answer  the  question,  what 
have  you  done  ? 

Authentication 

The  authentication  service  is  usually  the  first  service  that  a  user  will  experience 
before  he  can  proceed  to  perform  other  computing  tasks.  Since  all  other  security 
services  depend  on  authentication,  an  authentication  service  must  be  reliable  and 
robust.  Password  is  the  most  common  approach  to  authenticate  the  identity  of  a 
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user.  Password  is  a  secret  character  string  kept  by  both  a  user  and  the  authentication 
service.  Password  security  has  been  extensively  researched  and  many  guidelines  of 
selecting  good  passwords  that  are  hard  to  guess  have  been  proposed  [1,  2].  The 
secrecy  and  integrity  of  the  system  password  file  which  stores  the  passwords  of  all 
the  users  must  be  fully  protected.  Some  modern  computer  systems  use  smart  cards 
[3]  to  authenticate  users.  A  smart  card  is  a  device  held  by  a  user  and  embedded 
with  a  microprocessor,  memory,  and  algorithms  to  compute  an  identification  string 
with  the  user's  password  as  its  input.  The  advantages  of  smart  cards  are  that  the 
authentication  process  is  more  secure  than  simply  using  user  passwords  and  a  user  can 
login  to  a  computer  system  from  anywhere  if  there  is  a  smart  card  reader  (since  the 
encryption  algorithm  and  mechanism  are  provided  by  the  smart  card,  rather  than  by 
the  machine).  More  advanced  authentication  methods  use  biometric  authentication 
devices  [4]  to  recognize  a  user's  personal  characteristics  like  his/her  voice,  retina,  or 
fingerprints.  Showing  the  greatest  promise  of  authentication,  biometric  advices  need 
advanced  speech  or  image  processing  technology.  Their  high  costs  are  only  justified 
where  the  benefits  they  provide  are  absolutely  required. 

Authorization 

Each  access  of  a  user,  or  a  process  executing  on  behalf  of  him,  to  some  data 
storage  needs  to  be  controlled  by  the  authorization  service.  To  describe  how  data 
access  should  be  mediated,  explicit  and  well-defined  security  policies  or  access  control 
policies  need  to  be  defined.  An  access  control  policy  consists  of  a  set  of  rules  used 
by  the  system  to  determine  whether  an  access  attempt  by  a  user  to  a  specific  data 
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storage  should  be  granted  or  denied.  A  security  model  or  access  control  model  is  a 
formal  representation  (by  mathematical  notations  and  formalisms)  of  the  security 
policies  enforced  by  the  system.  It  offers  a  means  to  depict  how  each  data  access  is 
regulated  by  the  authorization  service.  Note  that  a  security  policy  is  defined  to  reflect 
the  security  requirements  of  an  organization  or  its  users,  and  should  be  established 
independent  of  any  security  models.  A  security  model  describes  how  each  access 
decision  is  determined,  in  order  not  to  violate  the  security  policy.  Naturally,  it 
is  desirable  to  choose  a  security  model  that  can  enforce  a  wide  variety  of  security 
pohcies. 

A  security  model  only  provides  an  abstract  concept  of  enforcement  of  security 
policies.  In  practice,  it  needs  to  be  realized  by  a  security  mechanism  or  access  con- 
trol mechanism  that  consists  of  hardware  and  software  features,  operating  functions, 
and  management  procedures  to  perform  the  activities  of  an  authorization  service. 
One  security  model  may  be  implemented  by  several  distinct  types  of  security  mecha- 
nisms, with  each  having  its  advantages  and  disadvantages  from  different  viewpoints 
of  management.  Regardless  of  how  powerful  a  security  model  is,  operation  efficiency 
of  a  security  mechanism  and  ease  of  its  management  framework  are  crucial  to  the 
applicability  of  a  security  model. 

Auditing 

The  auditing  service  can  be  thought  as  the  last  defense  line  of  a  secure  computer 
system,  because  once  other  security  services  fail  and  a  security  violation  occurs,  the 
auditing  log  can  be  reviewed  and  examined  to  trace  the  responsible  users  and  reveal 
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the  imperfection  of  security  mechanisms.  The  latter  often  provides  the  most  valuable 
information  for  improving  the  security  services  of  a  computer  system.  The  capability 
of  selecting  the  audit  events  to  be  recorded  is  necessary  to  minimize  the  expense  of 
auditing  and  to  allow  eflBcient  analysis.  For  obvious  reasons,  the  audit  data  itself 
must  be  protected  from  unauthorized  modification  and  destruction. 

1.2    Internetwork  Security 

The  requirements  of  information  security  within  an  organization  have  undergone 
a  major  change  in  the  last  several  decades  with  the  introduction  of  distributed  sys- 
tems and  the  use  of  networks  and  communication  facilities  for  carrying  data  between 
terminal  user  and  computer  and  between  computers.  Network  security  measures  are 
needed  to  protect  data  during  their  transmission.  In  fact,  the  term  network  security 
is  somewhat  misleading,  because  virtually  all  business,  government,  and  academic 
organizations  interconnect  their  data  processing  equipment  with  a  collection  of  inter- 
connected networks.  Such  a  collection  is  often  referred  to  as  an  internetworld ,  and 
internetwork  security  will  be  a  more  suitable  term  in  this  case. 

1.2.1    Securitv  Attacks 

The  types  of  attacks  on  the  security  of  a  computer  system  or  network  are  best 
characterized  by  viewing  the  function  of  the  computer  system  as  providing  informa- 
tion. In  general,  there  is  a  flow  of  information  from  a  source,  such  as  a  file  or  a  region 
of  main  memory,  to  a  destination,  such  as  another  file  or  a  user.  This  normal  flow  is 

^Not  to  be  confused  with  the  term  (DARPA)  Internet,  which  refers  to  a  specific  collection  of 
networks  that  has  become  something  of  a  global  public  networking  utility.  The  Internet  may  be  one 
of  the  facilities  used  by  an  organization  to  construct  its  internetwork. 
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Figure  1.1.  Four  categories  of  security  attacks 

depicted  in  Figure  1.1(a).  The  remaining  parts  of  the  figure  show  the  following  four 
general  categories  of  attack: 

•  Interruption  is  when  an  asset  of  the  system  is  destroyed  or  becomes  unavail- 
able or  unusable.  This  is  an  attack  on  availability.  Examples  include  destruction 
of  a  piece  of  hardware,  such  as  a  hard  disk;  the  cutting  of  a  communication 
line;  or  the  disabling  of  the  file  management  system. 

•  Interception  is  when  an  unauthorized  party  gains  access  to  an  asset.  This 
is  an  attack  on  confidentiality.  The  unauthorized  party  could  be  a  person,  a 
program,  or  a  computer.  Examples  include  wiretapping  to  capture  data  in  a 
network,  and  the  illicit  copying  of  files  or  programs. 

•  Modification  is  when  an  unauthorized  party  not  only  gains  access  to  but  tam- 
pers with  an  asset.  This  is  an  attack  on  integrity.  Examples  include  changing 
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values  in  a  data  file,  altering  a  program  so  that  it  performs  differently,  and 
modifying  the  content  of  messages  being  transmitted  in  a  network. 

•  Fabrication  is  when  an  unauthorized  party  inserts  counterfeit  objects  into  the 
system.  This  is  an  attack  on  authenticity.  Examples  include  the  insertion  of 
spurious  messages  in  a  network  or  the  addition  of  records  to  a  file. 

A  useful  categorization  of  these  attacks  is  in  terms  of  passive  attacks  and  active 
attacks.  Examples  of  passive  attacks  are  eavesdropping  or  monitoring  of  transmis- 
sions. The  goal  of  the  opponent  is  to  obtain  information  that  is  being  transmitted. 
Two  types  of  attacks  are  involved  here:  release  of  message  contents  and  traffic  analy- 
sis. Active  attacks  involve  some  modification  of  the  data  stream  or  creation  of  a  false 
stream  and  can  be  subdivided  into  four  categories:  masquerade,  replay,  modification 
of  messages,  and  denial  of  service.  The  security  services  discussed  in  the  previous 
section  encounter  these  security  attacks  and  make  use  of  one  or  more  security  mech- 
anisms to  provide  the  services. 

1.2.2    Internetwork  Security  Models 

A  general  model  for  internetwork  security  is  shown  in  Figure  1.2.  Messages 
are  transferred  from  one  party  to  another  across  an  internetwork.  The  two  parties, 
who  are  the  principals  ^  in  this  transaction,  must  cooperate  for  the  information 
exchange  to  take  place.  A  logical  information  channel  is  established  by  defining  a 

^The  entities  in  a  networked  or  distributed  system  that  can  be  distinctly  identified  are  collectively 
referred  to  as  principals. 
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Figure  1.2.  A  model  for  internetwork  security 

route  through  the  internetwork  from  source  to  destination  and  by  the  cooperative 
use  of  communication  protocols  (e.g.,  TCP/IP)  by  the  two  principals. 

Security  aspects  come  into  play  when  it  is  necessary  or  desirable  to  protect  the 
information  transmission  from  an  opponent  who  may  present  a  threat  to  confiden- 
tiality, authenticity,  and  so  on.  All  the  techniques  for  providing  security  have  two 
components: 


•  A  security-related  transformation  on  the  information  to  be  sent.  Examples 
include  the  encryption  of  the  message,  which  scrambles  it  so  that  it  is  unread- 
able by  the  opponent,  and  the  addition  of  a  code  based  on  the  contents  of  the 
message,  which  can  be  used  to  verify  the  identity  of  the  sender. 

•  Some  secret  information  shared  by  the  two  principals  and,  hopefully,  unknown 
to  the  opponent.  An  example  is  an  encryption  key  used  in  conjunction  with  the 
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transformation  to  scramble  the  message  before  transmission  and  unscramble  it 
on  reception. 

A  trusted  third  party  may  be  needed  to  achieve  secure  transmission.  For  exam- 
ple, a  third  party  may  be  responsible  for  distributing  the  secret  information  to  the 
two  principals  while  keeping  it  from  any  opponent.  A  third  party  may  be  needed 
to  arbitrate  disputes  between  the  two  principals  concerning  the  authenticity  of  a 
message  transmission. 

This  general  model  shows  us  that  there  are  four  basic  tasks  in  designing  a 
particular  security  service: 

1.  Design  an  algorithm  for  performing  the  security- related  transformation.  The 
algorithm  should  be  such  that  an  opponent  cannot  defeat  its  purpose. 

2.  Generate  the  secret  information  to  be  used  with  the  algorithm. 

3.  Develop  methods  for  the  distribution  and  sharing  of  the  secret  information. 

4.  Specify  a  protocol  to  be  used  by  the  two  principals  that  makes  use  of  the  security 
algorithm  and  the  secret  information  to  achieve  a  particular  security  service. 

1.2.3    Access  Control  in  Internetwork 

There  are  other  security-related  situations  of  interest  that  do  not  neatly  fit  in 
this  model  but  that  are  important  in  internetwork  environment.  A  general  model  of 
these  situations  is  illustrated  by  Figure  1.3,  which  reflects  a  concern  for  protecting 
an  information  system  from  unwanted  access. 
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Figure  1.3.  Model  for  internetwork  access  security 

Traditional  internetworks  often  ignore  the  issue  of  interdomain  access  control, 
either  because  they  connect  organizations  within  a  large  administrative  unit  such  as 
university  or  government,  or  because  they  connect  research  institutions  with  little 
need  to  limit  information  flow.  With  increasing  internetwork  applications,  emerging 
internetworks  are  frequently  required  to  connect  administrative  domains,  or  ADs^, 
that  may  have  competing  interests.  In  this  environment,  unauthorized  access  to  net- 
work resources  is  an  issue  of  growing  concern  since  security  threats  and  the  damage 
associated  with  such  unauthorized  accesses,  can  be  very  high.  Therefore,  ADs  should 
be  able  to  interconnect  without  exposing  their  internal  resources  to  unrestricted  ex- 
ternal access.  Moreover,  internetwork  components  should  be  able  to  control  incoming 
and  outgoing  traflfic  by  specifying  or  constraining  the  ADs  to,  and  through  which,  the 
traffic  can  flow.  Therefore,  it  is  necessary  to  implement  an  access  control  mechanism 
to  protect  these  resources.  To  do  this,  all  of  the  access  control  requirements  should 
be  specified  clearly. 

^An  AD  is  defined  as  a  collection  of  network  resources  under  control  of  a  single  administrative 
entity  [5] 
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Access  control  requirements 

Due  to  the  characteristics  of  the  internetwork  discussed  above,  some  security 
measures  are  required  to  protect  resources  from  unauthorized  accesses.  However,  in 
an  internetwork,  the  goal  is  not  simply  to  prohibit  access  by  outsiders;  some  outside 
access  is  explicitly  desired.  The  goal  is  to  support  access  to  certain  machines,  ser- 
vices, and  processes,  while  preventing  access  to  all  other  internal  facilities.  Therefore, 
it  is  not  desirable  that  externally  accessible  facilities  be  physically  isolated  from  all 
strictly  internal  resources  for  this  would  interfere  with  internal  access  to  local  infor- 
mation and  resources.  Similarly,  requiring  that  all  internal  facilities  adopt  additional 
security  measures  to  cope  with  external  connections  may  interfere  with  internal  com- 
munication and  resource  sharing.  This  measure  also  requires  global  knowledge  of  all 
interconnections.  Therefore,  it  is  desirable  to  implement  logical  networks  that  can  be 
isolated  from  one  another  yet  share  physical  resources. 

To  achieve  this  goal  more  effectively,  only  the  administrators  of  the  external 
Hnks,  gateways,  and  the  internal  resources  that  are  made  explicitly  accessible  should 
be  required  to  take  security  action  in  response  to  an  external  connection.  Owners  of 
all  other  internal  resources  should  be  assured  that  their  facilities  are  not  accessible 
to  outsiders.  Therefore,  each  organization  must  control  all  exit  and  entry  points  to 
its  internal  network  assuming  no  direct  external  connections  are  permitted  without 
going  through  one  of  these  control  points.  This  minimizes  interference  with  the 
organization's  internal  facilities  and  operations.  However,  this  approach  does  impose 
new  requirements  on  the  functionality  of  gateways  and  the  communication  protocols 
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used.  In  other  words,  this  nondiscretionary  control  mechanisms  in  the  gateway  should 
have  access  to  logical  information  about  packets,  such  as  organizational  affiliation  of 
source  and  destination. 

Finally,  the  costs  imposed  by  a  control  scheme  should  be  minimized.  That  is, 
per-packet  processing  and  storage  overhead  in  border  router  and  end-system,  addi- 
tional communication  during  connection  setup,  and  packet  length  overhead  should 
be  minimized.  Other  costs  such  as  router  crash  should  also  be  minimized. 

Classification  of  access  controls 

An  internetwork  is  composed  of  a  number  of  Administrative  Domains,  or  ADs  as 
discussed  in  previous  sections.  It  is  important  to  distinguish  between  two  dominant 
types  of  ADs:  stub  and  transit.  Stub  ADs  are  interested  mainly  in  communication 
with  other  stub  ADs,  that  is,  providing  communication  for  their  constituent  end- 
systems.  A  campus  network  is  an  example  of  a  stub  AD.  Transit  ADs  are  involved 
in  providing  transit  service  for  traffic  between  stub  ADs.  NSFNET  is  an  example  of 
a  transit  AD.  Finally,  there  are  also  hybrid  ADs  that  combine  transit  service  with 
end-point  communication. 

Considering  these  types  of  ADs,  an  internetwork  access  control  scheme  can  be 
devided  into  two  parts:  stub  network  access  control  and  transit  network  access  con-, 
trol.  Stub  network  access  control  is  concerned  with  policy  enforcement  with  respect 
to  non-transit  internetwork  traflUc.  In  other  words,  the  issue  is  how  an  AD  can  control 
both  inbound  (addressed  to  a  local  end-system)  and  outbound  (sourced  by  a  local 
end-system)  traffic  at  its  network  boundaries.  On  the  other  hand,  transit  network 
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access  control  is  concerned  with  policy  enforcement  with  respect  to  transit  internet- 
work traffic.  Controlling  access  to  transit  network  resources  (such  as  routers  and 
links)  requires  additional  protocol  support  because  of  the  need  to  coordinate  routing 
decisions  among  all  intervening  networks.  These  two  access  controls  should  work  in 
harmony  to  achieve  a  dependable  policy  enforcement  in  an  internetwork  environment. 


CHAPTER  2 
BACKGROUND  AND  LITERATURE  REVIEW 

2.1  Preamble 

The  research  work  in  this  dissertation  falls  into  three  main  areas  of  computer  and 
communications  security:  internetwork  access  control,  interdomain  authentication, 
and  secure  control  of  internetwork  transit  traffic.  In  each  of  these  research  axeas, 
the  problems  found,  the  methods  used,  and  the  results  achieved  will  be  discussed  in 
detail  in  a  separate  chapter.  A  thorough  overview  of  previous  research  in  these  fields 
is  given  in  this  chapter. 

2.2    Internetwork  Access  Control 

There  have  been  many  works  on  internet  security.  Kent  and  Voydock  suggested 
some  security  mechanisms  in  high-level  network  protocols  in  their  early  works  [6,  7]. 
Branstad  et  al.  [8]  and  Nelson  [9]  have  presented  the  development  of  a  security 
architecture  for  secure  data  network  system  (SDNS)  project  within  the  International 
Standardization  Organization's  (ISO)  Open  Systems  Interconnection  (OSI)  computer 
network  reference  model.  They  have  developed  a  Security  Protocol  (SP4)  at  the 
ISO  transport  layer  to  provide  either  connectionless  or  connection-oriented  security 
services.  The  importance  of  placing  different  security  services  at  various  layers  of  the 
OSI  architecture  are  discussed  by  Ramaswamy  and  Fumy  [10,  11].  Since  Bellovin 


14 


15 


[12]  pointed  out  some  security  breaches  in  DOD's  TCP/IP  protocol  suite,  many 
suggestions  [13,  14,  15,  16]  have  been  made  to  address  internet  security  problems. 
Most  of  these  works  are  on  providing  confidentiality  and  integrity  of  information  in 
transit  by  either  inserting  a  security  sublayer  or  modifying  existing  protocol  layers  to 
utilize  existing  cryptographic  tools. 

With  increasing  internetwork  application,  emerging  internetworks  are  frequently 
required  to  connect  ADs  that  may  have  competing  interests.  Therefore,  ADs  are 
required  to  control  accesses  to  the  local  resources  by  enforcing  policies  at  their  bor- 
derline. There  have  been  a  stream  of  research  works  that  focus  on  the  resource  access 
control  in  internetworked  or  distributed  systems: 

•  The  firewall  approach  isolates  an  AD's  internal  networks  from  the  outside  world 
with  special  machines  called  firewalls.  Conceptually,  there  are  two  types  of 
firewalls:  network  level  and  application  level. 

•  The  distributed  systems  approach  provides  an  access  control  as  a  part  of  a 
more  comprehensive  security  service  for  a  certain  distributed  system.  This 
often  requires  substantial  software  modification  to  take  advantage  of  it  since  the 
security  service  is  normally  well  integrated  within  the  fundamental  distributed 
services. 

•  The  packet-level  authentication  approach  enforces  access  control  policy  on  packet 
level.  That  is,  border  routers  examine  traffic  flows  so  that  only  the  packets  with 
proper  authenticator  are  allowed  to  exit  from  a  local  domain  and  to  enter  into 
a  destination  domain. 
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2.2.1    Firewall  Approach 

A  firewall  is  a  system  or  a  group  of  systems  that  enforces  an  access  control  policy 
between  two  networks.  The  actual  means  whereby  this  is  accomplished  varies  widely, 
but  in  principle,  the  firewall  can  be  thought  of  as  a  pair  of  mechanisms:  one  to  block 
traffic,  and  the  other  to  permit  traffic.  Some  firewalls  place  a  greater  emphasis  on 
blocking  traffic,  while  others  emphasize  permitting  traflRc.  Firewalls  can  be  classified 
into  two  main  categories:  network  level  firewall  and  application  level  firewall. 

Network  level  firewalls  generally  make  their  decisions  based  on  the  source,  des- 
tination addresses  and  ports  in  individual  IP  packets  as  in  screend  [17,  18]  and  in 
TAMU  [19].  In  general,  no  context  is  kept;  decisions  are  made  based  only  on  the 
contents  of  the  current  packet.  The  administrator  maintains  a  list  of  the  acceptable 
machines  and  services  and  a  stoplist  of  unacceptable  machines  or  services.  However, 
this  approach  works  only  if  the  lists  are  static  or  if  the  source  and  destination  ID's 
carry  suflScient  information  for  access  decisions.  In  other  words,  if  there  is  a  well- 
defined  set  of  resources  that  are  to  be  accessible  by  a  well-defined  set  of  entities, 
then  the  access  control  list  could  be  managed  manually.  Alternatively,  if  internet  ad- 
dresses are  structured  in  such  a  way  that  the  gateway  can  classify  a  node  according  to 
the  range  into  which  its  internet  address  falls,  the  gateway  could  maintain  an  access 
control  list  by  node  classes  (internet  address  regions),  and  thereby  achieve  greater 
flexibility. 

I  am  interested  in  the  more  general  case  of  a  dynamic  environment  where  network 
addresses  by  themselves  do  not  provide  sufficient  information  for  the  gateway  to  make 
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a  policy  decision  about  whether  or  not  to  permit  access;  the  DARPA  Internet  is  one 
such  environment.  Internet  addresses  are  assigned  to  carry  topological,  not  logical, 
information  [20],  while  policy  decisions  are  generally  based  on  the  latter.  Moreover, 
if  the  gateway  relies  solely  on  the  addresses  to  control  the  access,  the  gateway  must 
trust  all  internal  nodes  not  to  masquerade  as  other  nodes,  that  is,  not  to  fake  their 
internet  addresses.  In  reality,  it  is  not  hard  to  modify  one's  internet  address  in  a 
decentralized  environment  with  many  personal  computers  and  workstations.  The 
packet  level  firewall  cannot  detect  this  address  spoofing  attack. 

Application  level  firewalls  generally  are  hosts  running  proxy  servers  ^,  which 
permit  no  traffic  directly  between  networks  [21,  22].  A  proxy  server  is  an  application 
that  mediates  traffic  between  a  protected  network  and  the  Internet.  Proxies  are  often 
used  instead  of  router-based  traffic  controls,  to  prevent  traffic  from  passing  directly 
between  networks.  Proxies  must  "understand"  the  application  protocol  being  used 
and  the  protocol  specific  security  should  be  configured  (e.g.,  an  FTP  proxy  might  be 
configurable  to  permit  incoming  FTP  and  block  outgoing  FTP). 

Proxy  servers  are  application  specific.  In  order  to  support  a  new  protocol  via  a 
proxy,  a  proxy  must  be  developed  for  it.  Moreover,  having  an  application  in  the  way 
in  some  cases  may  impact  performance  and  may  make  the  firewall  less  transparent. 
Early  application  level  firewalls  such  as  those  built  using  the  TIS  firewall  toolkit, 
are  not  particularly  transparent  to  end  users  and  may  require  some  training.  One 
popular  set  of  proxy  servers  is  the  TIS  Internet  Firewall  Toolkit  (FWTK)  which 
^It  is  sometimes  referred  to  as  an  application  forwarder  or  a  application  gateway 
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includes  proxies  for  telnet,  rlogin,  FTP,  X- window,  HTTP/Web,  and  NNTP/Usenet 
news.  SOCKS  [23]  is  a  generic  proxy  system  that  can  be  compiled  into  a  client-side 
application  to  make  it  work  through  a  firewall. 

While  suitable  for  some  situations,  high-level  gateways  suffer  from  performance 
overhead  of  the  gateway's  high-level  processing,  and  reduced  generality  and  flexibility, 
since  special  high-level  gateway  software  must  be  constructed  for  each  high-level 
protocol  supported.  Thus,  it  would  be  desirable  to  implement  access  control  in 
internet  gateways  without  incurring  the  costs  inherent  to  high-level  gateways. 

2.2.2    Distributed  Systems  Approach 

The  Open  Software  Foundation's  (OSF's)  Distributed  Computing  Environment 
(DCE)  [24]  is  a  comprehensive,  integrated  set  of  services  that  supports  the  devel- 
opment, use  and  maintenance  of  distributed  applications.  DCE  Security  Service 
includes  several  components:  a  DCE  authentication  service,  privilege  service,  reg- 
istry service,  authenticated  RPC,  and  DCE  access  control  lists.  DCE  authentication 
service  was  built  upon  the  Kerberos  V5  source  code  from  MIT's  Project  Athena. 
Privilege  service  allows  users  to  be  identified  by  individual  user  privilege  and  by 
group  membership.  The  user  registry  ensures  the  use  of  unique  user  names  and  pass- 
words across  the  distributed  network  of  systems  and  services,  ensures  the  accuracy 
and  consistency  of  this  information  at  all  sites,  and  provides  security  for  updates  and 
changes.  It  maintains  a  single,  logical  database  of  user  account  information  including 
user  and  group  naming  information,  login  account  information,  and  general  system 
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properties  and  policies.  It  is  well  integrated  with  Kerberos  to  provide  an  integrated, 
secure,  reliable  user  account  management  system. 

The  DCE  security  service  component  is  well  integrated  within  the  fundamental 
distributed  service^  and  data-sharing  components^  of  DCE.  Therefore,  DCE  security 
service  alone  cannot  be  used  in  internetwork  environment  to  enforce  any  access  control 
policy  since  it  was  not  designed  to  be  used  stand-alone  security  service.  In 

other  words,  DCE  security  service  is  a  part  of  a  distributed  computing  environment 
architecture  that  goes  beyond  simple  communication  facility  and  provides  a  wide 
range  of  computer  services  to  applications  regardless  of  the  location  of  the  user,  the 
application,  or  the  required  resources. 

On  the  other  hand,  in  many  internets,  such  as  DARPA  Internet,  hosts  are  not 
coupled  as  tightly  as  in  distributed  systems.  They  are  just  interconnected  hosts  in 
many  different  ADs.  These  host  are  not  often  interested  in  anything  beyond  using 
some  internetwork  appHcations  such  as  FTP,  e-mail,  telnet,  or  WWW  service  with 
security.  Therefore,  it  is  not  reasonable  to  require  these  hosts  to  change  their  system 
environment  to  DCE  in  order  to  use  DCE  security  service.  A  less  elaborate  and 
immediate  measure  will  be  desirable  to  provide  access  control  service  in  this  environ- 
ment. It  would  be  great  if  an  efficient  access  control  scheme  can  be  implemented  by 
just  modifying  a  protocol  layer,  preferably  in  lower  layers. 

As  mentioned  earlier,  DCE  authentication  service  is  based  on  Kerberos  V5. 
That  is,  an  inter-cell  authentication  (inter-realm  authentication  in  Kerberos  term) 

^This  includes  remote  procedure  call,  directory  service,  time  service,  security  service,  and  threads 
service 

^This  includes  distributed  file  system  and  diskless  support 
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is  performed  by  a  pairwise  security  sharing  [25]  or  by  a  realm  hierarchy  [26].  This 
will  give  difficulties  for  hosts  in  DCE  environment  to  authenticate  principals  in  non- 
DCE  ADs.  Instead,  it  is  not  allowed  to  get  service  from  those  servers  outside  of 
the  distributed  system.  It  would  be  desirable  to  be  able  to  accomplish  interdomain 
authentications  without  much  change  in  system  and  network  environment  for  many 
ADs. 

Finally,  DCE  Security  Service  is  based  on  the  Client-Server  paradigm.  However, 
this  is  not  always  the  case  with  internetworks.  An  effective  access  control  scheme 
should  work  well  with  both  client-server  and  peer-to-peer  communications. 

The  Secure  European  System  for  Applications  in  a  Multi-vendor  Environment 
(SESAME)  [27]  by  European  Computer  Manufacturer's  Association  (ECMA)  is  an 
approach  similar  to  DCE  Security  Service  except  for  some  implementation  details. 
SESAME  implementation  also  includes  Kerberos  V5  features  and  components  as  a 
core  of  the  authentication  service.  Authentication  Service  extension  provides  support 
for  authentication  based  on  public  key  technology.  SESAME  shares  the  same  char- 
acteristics as  a  security  measure  for  distributed  systems  as  DCE  Security  Service  and 
is  not  considered  appropriate  to  be  used  as  an  access  control  scheme  in  internetwork 
environments. 

2.2.3    Packet-Level  Authentication  Approach 

The  VISA  scheme  [28,  29]  implements  controls  in  a  packet-forwarding-  gateway 
by  working  in  concert  with  an  access  control  server  (ACS).  The  ACS  carries  out  the 
high-level  evaluation  of  communication  requests  and  the  gateway  enforces  the  ACS's 
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decision  using  the  VISA  scheme.  That  is,  a  gateway  only  allows  a  packet  with  a 
valid  exit  visa  stamp  to  exit  from  and  a  packet  with  a  valid  entry  visa  stamp  to 
enter  into  its  network.  A  visa  stamp  is  a  mathematical  value  calculated  from  packet 
authentication  keys  called  visa.  However,  this  scheme  requires  the  distribution  of 
visas  in  plain  text  for  each  external  session.  This  requires  extra  security  measures  to 
transport  the  visas  to  hosts  requesting  external  sessions  safely.  Hence,  the  security 
of  the  mechanism  depends  largely  on  the  protection  of  the  visas  during  distribution. 
Moreover,  VISA  scheme  does  not  specify  any  authentication  protocol  for  the  session 
initiation  stage.  The  lack  of  an  interdomain  authentication  mechanism  makes  this 
scheme  less  attractive  in  an  internetwork  environment  with  heterogeneous  authenti- 
cation protocols. 

Another  packet-level  access  control  scheme  proposed  by  Iqbal  et  al.  [30]  for- 
mulated an  approach  for  authenticating  individual  packets  from  a  host  for  the  dura- 
tion of  an  external  session  without  distributing  packet  authentication  keys.  In  this 
scheme,  a  chain  of  pairwise  authentications  between  neighboring  principals  on  the 
path  from  the  source  to  the  destination  host  should  be  accomplished  during  the  ses- 
sion initiation  procedure.  This  pairwise  authentication  is  based  on  the  RSA  public 
key  cryptosystem  to  verify  each  other's  identification.  For  a  specific  session,  each  pair 
shares  a  distinct  mathematical  value  called  a  reference  number  to  be  used  to  extract 
a  packet  authentication  key  from  the  RSA  private  key  which  is  shared  by  the  pair. 
After  the  session  initiation,  each  valid  packet  should  contain  a  packet  authentication 
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code  (PAC)  which  is  computed  from  the  packet  authentication  key  using  DES  algo- 
rithm. This  requires  peer  communicating  entities,  including  network  access  control 
gateways  (NACGs)  in  different  organizations,  to  share  their  RSA  private/public  key 
pairs.  This  increases  vulnerability  tremendously  since  the  compromise  of  any  one 
gateway  can  make  other  gateways  in  other  organizations  subject  to  attack  when  they 
share  RSA  private  keys.  This  is  not  desirable  in  today's  competing  and  hostile  in- 
ternet environment.  Moreover,  for  all  but  the  nearby  hosts,  the  overhead  due  to  the 
consecutive  pairwise  authentications  becomes  large. 

2.3    Interdomain  Authentication 

In  an  internetwork  environment  any  two  principals  on  different  machines  need 
to  authenticate  each  other  before  starting  communication  so  that  a  network  intruder 
cannot  impersonate  a  principal  to  the  other.  There  are  three  types  of  authentication 
in  this  environment: 

•  message  content  authentication,  verifying  that  the  content  of  a  received  message 
is  the  same  as  when  it  was  sent; 

•  message  origin  authentication,  verifying  that  the  sender  of  a  received  message 
is  the  same  one  recorded  in  the  sender  field  of  a  message;  and 

•  general  identity  authentication,  verifying  that  a  principal's  identity  is  as  claimed. 

Message  content  authentication  is  commonly  handled  by  tagging  a  key-dependent 
message  authentication  code  (MAC)  onto  a  message  before  it  is  sent.  Message  in- 
tegrity can  be  confirmed  upon  reception  by  recomputing  the  MAC  and  comparing  it 
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with  the  one  attached.  Message  origin  authentication  is  a  subcase  of  general  identity 
authentication.  A  successful  general  identity  authentication  usually  results  in  a  belief 
held  by  the  authenticating  principal  (the  verifier)  that  the  authenticated  principal 
(the  claimant)  possesses  the  claimed  identity.  Hence,  subsequent  claimant  actions 
are  attributable  to  the  claimed  identity. 

Authentication  is  achieved  usually  based  upon  cryptography  and  by  using  the 
authentication  server  that  is  trusted  by  all  principals  in  one  administrative  domain. 
The  authentication  server  shares  a  unique  master  key  with  each  principal,  and  all 
the  authentication  information  are  conveyed  between  the  server  and  a  principal  by 
encrypting  them  with  the  master  key  of  the  principal.  To  authenticate  its  identity,  a 
principal  must  demonstrate  the  ability  of  recognizing  the  authentication  information 
encrypted  with  his  own  master  key,  but  without  revealing  it,  to  the  other  principal. 

Furthermore,  distributed  applications  frequently  require  that  the  messages  trans- 
mitted over  the  network  be  confidential  only  to  the  communicating  peers,  which  im- 
plies at  least  a  session  key  needs  to  be  distributed  first  between  two  communicating 
principals  before  a  session  of  confidential  data  transmission  between  them  can  ini- 
tiate. This  session  key  is  also  used  to  provide  message  origin  authentication  during 
data  communication  following  an  authentication  process.  That  is,  any  message  en- 
crypted with  the  session  key  after  authentication  is  assumed  to  originate  from  the 
peer  principal  who  holds  the  session  key.  The  distribution  of  a  session  key  is  often 
carried  out  concurrently  with  the  authentication  process. 
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2.3.1    Authentication  Protocols 
Protocols  using  private  key  encryption 

In  1978  Needham  and  Schroeder  proposed  the  use  of  encryption  for  authentica- 
tion in  computer  networks  [31].  The  proposed  protocols  use  private  key  encryption 
as  well  as  public  key  encryption.  Since  the  principals  are  identified  by  a  secret  key, 
an  authentication  server  is  used  which  stores  the  names  of  the  principals  and  the  keys 
belonging  to  them.  This  work  is  the  starting  point  for  many  authentication  protocols 
that  have  since  been  developed. 

Denning  and  Sacco  [32]  pointed  out  a  flaw  in  the  private  key  authentication 
protocol  proposed  by  Needham  and  Schroeder.  They  proposed  to  use  timestamps 
to  overcome  the  vulnerability  of  replay  attack.  But  this  approach  has  the  drawback 
that  it  requires  an  accurate  distributed  clock  and  synchronization  which  is  diflScult 
to  achieve. 

In  1987  Needham  and  Schroeder  again  published  a  protocol  that  avoids  the 
security  deficits  shown  by  Denning  and  Sacco  by  using  nonces  [33].  Their  proposal 
requires  an  extra  interaction  between  the  two  communicating  principals  but  doesn't 
depend  on  synchronized  clocks. 

Otway  and  Rees  [34]  described  a  protocol  for  efficient  mutual  authentication 
that  also  eliminates  the  weakness  discovered  by  Denning  and  Sacco.  Their  protocol 
is  a  development  of  the  trusted  third  party  authentication  protocols  of  Needham  and 
Schroeder  [31].  It  requires  a  total  of  only  four  messages  to  be  exchanged  between  the 
three  parties  involved. 
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Kerberos  [25,  26]  is  an  authentication  service  that  was  built  for  MIT's  Project 
Athena.  Kerberos  is  based  on  the  Needham  and  Schroeder  third  party  authentication 
model  [31]  and  uses  timestamps  to  prevent  re-use  of  tickets  or  replay.  It  requires  a 
physically  secure  authentication  server.  Kerberos  uses  the  Data  Encryption  Standard 
(DES)  and  is  therefore  not  exportable.  Some  limitations  of  Kerberos  version  4  [25] 
are  pointed  out  by  Bellovin  and  Merritt  [35].  Kerberos  version  5  [26]  addressed  most 
of  these  problems. 

Kehne  et  al.  [36]  developed  a  nonce-based  protocol  that  offers  the  same  features 
as  Kerberos  without  the  need  of  synchronized  clocks.  They  show  that  their  protocol 
uses  a  minimum  number  of  messages  to  establish  an  authentication  session  key. 

Protocols  using  public  key  encrvption 

ITU-T  Recommendation  X.509  [37]  proposed  an  authentication  protocol  based 
on  public  key  encryption  that  uses  a  one-way  handshake.  The  protocol  needs  an 
authentication  server  which  stores  public  key  certificates  for  those  who  wajit  to  verify 
the  identity  of  a  communication  partner.  Since  the  certificates  cannot  be  forged  the 
requirements  for  the  authentication  server  are  not  as  strong  as  those  for  authentica- 
tion using  private  key  encryption. 

Another  approach,  proposed  by  Woo  and  Lam  [38],  makes  use  of  nonces  in 
the  authentication  protocol.  This  protocol  has  a  vulnerability  to  replay  attack  and 
they  published  a  revised  version  [39]  and  showed  the  design  steps  of  flawless  security 
protocol. 
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SPX  [40]  is  an  implementation  of  an  open  distributed  authentication  service 
architecture  based  on  ISO  Standard  9594-8/ITU-T  X.509  Directory  Public  Key  Cer- 
tificates. Its  use  is  intended  for  open  network  environments.  It  doesn't  require  on-line 
trusted  components.  SPX  is  an  initial  subset  implementation  of  a  larger  security  ar- 
chitecture called  as  Digital's  Distributed  Systems  Security  Architecture  (DSSA). 

Assuring  freshness  of  messages 

In  general,  all  the  authentication  protocols  for  distributed  systems  can  be  di- 
vided into  two  categories  depending  upon  how  the  freshness  of  key-distribution  mes- 
sages is  determined.  One  category  of  protocols  uses  nonces.  They  exchange  chal- 
lenge/response messages  to  verify  whether  the  response  to  a  key  distribution  request 
is  fresh  or  not.  Since  replay  attacks  can  be  effectively  prevented  by  the  use  of  nonces 
without  clock  synchronization,  most  proposed  protocols  in  the  literature  are  nonce- 
based  [31,  33,  34,  36,  41,  42]. 

The  other  category  of  protocols  uses  timestamps  to  ensure  the  freshness  of  mes- 
sages. These  protocols  must  assume  that  all  machines  are  properly  clock-synchronized. 
The  number  of  messages  required  by  timestamp-based  protocols  can  be  reduced  since 
no  round-trip  traffic  is  required  to  guarantee  message  freshness  as  in  the  case  of 
nonce-based  protocols.  However,  due  to  the  imperfection  of  clock  synchronization 
[43],  timestamp-based  protocols  are  vulnerable  to  both  conventional  copy-and-replay 
and  suppress-and-play  attacks  elaborated  by  Gong  [44]. 
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2.3.2    Interdomain  Authentication  Protocols 

General  identity  authentication  is  required  between  a  local  host  and  the  local 
authentication  server  to  verify  that  a  principal's  identity  is  as  claimed.  Similar  au- 
thentication is  needed  between  a  pair  of  principals  in  different  administrative  domains 
to  initiate  a  session  between  them.  The  intradomain  authentication  is  relatively  sim- 
ple and  can  be  accomplished  easily  using  any  authentication  protocol  available  locally 
such  as  Kerberos  [26].  However,  the  interdomain  authentication  requires  additional 
mechanisms  since  it  is  not  always  reasonable  to  assume  the  existence  of  a  single 
trusted  authentication  server  between  any  two  ADs  in  the  internet  environment. 

As  a  part  of  Project  Athena  at  MIT,  Kerberos  [25,  26,  45]  is  one  of  the  most 
promising  implementations  of  the  authentication  service.  It  is  based  on  the  Needham- 
Schroeder  protocol  and  uses  timestamps  suggested  by  Denning  and  Sacco  [32]  to 
prevent  replays  and  to  reduce  messages  complexity.  Because  of  its  simplicity  and 
reliability,  Kerberos  has  now  become  the  most  popular  authentication  service  and 
adopted  by  a  number  of  vendors  in  designing  distributed  systems. 

Kerberos  is  designed  on  a  client-server  model,  thus  it  provides  authentication 
service  between  a  client  and  a  server  when  the  former  tries  to  request  a  service 
from  the  latter.  In  fact,  Kerberos  places  the  authentication  service  on  two  kinds  of 
servers:  Kerberos  server  and  ticket  granting  server  (TGS).  While  the  Kerberos  server 
authenticates  the  user  when  he  logins  and  issues  a  ticket  for  a  TGS,  it  is  the  TGS 
that  issues  tickets  for  individual  servers  to  a  client.  The  limitations  and  weaknesses 
of  the  Kerberos  system  have  been  explored  by  Bellovin  and  Merritt  [35],  and  most  of 
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them  are  due  to  the  use  of  timestamps.  While  the  initial  version  of  Kerberos  is  based 
upon  a  secret-key  cryptosystem,  the  public-key  cryptosystem  has  been  incorporated 
into  the  version  5. 

Kerberos  provides  a  mechanism  for  supporting  inter-realm  authentication.  The 
scheme  requires  that  the  Kerberos  server  in  one  realm  trust  the  Kerberos  server  in  the 
other  realm  to  authenticate  its  users.  Kerberos  V4  [25]  uses  a  pairwise  secret  sharing 
to  perform  inter-realm  authentication,  which  has  a  scalability  problem.  That  is,  if 
there  are  A'^  realms,  then  there  must  be  N{N -l)/2  secure  key  exchanges  so  that  each 
Kerberos  realm  can  interoperate  with  all  other  Kerberos  realms.  Kerberos  V5  uses 
authentication  forwarding  and  realm  hierarchy  to  solve  this  problem  in  inter-realm 
authentication. 

Another  approach  suggested  a  hierarchical  authentication  [46].  That  is,  it  sug- 
gested higher-level  authentication  servers  that  act  as  authentication  servers  for  the 
lower-level  authentication  servers  in  different  domains.  The  layers  of  authentication 
servers  can  be  extended  further  to  cover  larger  number  of  domains.  However,  it  is 
not  reasonable  to  assume  that  there  exists  always  such  a  higher-level  authentication 
server  that  can  be  trusted  by  all  competing  and  sometimes  hostile  ADs.  Another 
well-known  authentication  service  based  upon  the  public-key  cryptosystem  is  SPX 
[40]  developed  by  DEC.  It  suggested  an  interdomain  authentication  protocol  and 
proposed  a  design  of  a  proprietary  certification  system  to  provide  public  keys  to  the 
principals. 
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2.3.3    Formal  Protocol  Analysis  and  Evaluation 

Most  authentication  protocols  found  in  the  literature  are  described  only  by  list- 
ing the  messages  sent  between  principals  and  by  explaining  what  results  will  be 
achieved  after  each  step  of  message  transmission,  in  quite  an  informal  and  imprecise 
way.  To  formalize  the  definition  of  a  protocol,  Burrows,  Abadi,  and  Needham  de- 
fined a  logic  of  authentication  [42,  47]  (hereafter  called  BAN  Logic)  to  describe  the 
initial  assumptions  upon  which  a  protocol  is  based  and  the  meaning  of  each  mes- 
sage in  a  logical  and  precise  way,  and  to  express  exactly  what  final  beliefs  can  be 
obtained  by  communicating  principals  after  the  completion  of  a  protocol  run.  They 
demonstrated  the  strength  of  BAN  Logic  by  applying  the  logic  to  a  number  of  au- 
thentication protocols  and  evaluating  the  nature  of  the  guarantees  those  protocols 
offer.  In  their  well-known  paper  introducing  BAN  Logic,  the  formalized  goals  of 
authentication  were  explicitly  stated,  and  the  protocols  which  cannot  achieve  these 
goals  were  appropriately  criticized  and  improved  wherever  possible. 

2.4    Secure  Control  of  Transit  Internetwork  Traffic 

Network  access  control  methods  that  restrict  the  information  flow  between  end- 
systems  on  stub  domains  have  been  discussed  in  previous  sections.  However,  control- 
ling access  to  transit  network  resources  (such  as  routers  and  links)  require  additional 
protocol  support  because  of  the  need  to  coordinate  routing  decisions  among  all  in- 
tervening networks.  Organizations  cannot  simply  enforce  policy  restrictions  on  a 
unilateral  basis  at  packet  forwarding  time.  Internetwork  routing  decisions  must  be 
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made  according  to  policy- related  parameters  such  as  access  rights  and  cost,  in  addi- 
tion to  the  traditional  parameters  of  connectivity  and  delay  [48,  49].  Consequently, 
policies  pertaining  to  network  resources  must  either  be  implicit  in  the  topology  of  an 
internetwork,  or  advertised  to  the  anticipated  resource  users.  Only  then  can  entities 
throughout  the  internetwork  determine  the  logical,  policy-based  connectivity  of  an 
internetwork  and  compute  valid  routes. 

2.4.1    Issues  in  Internetwork  Environments 

This  section  defines  some  of  terminology  and  assumptions  regarding  internet- 
work environments  in  order  to  provide  appropriate  background  for  the  subsequent 
discussion. 

Internetwork  topology 

Some  routing  protocols  such  as  Exterior  Gateway  Protocols  (EGP)  [50]  place 
restrictions  on  internet  scale  and  topology.  However,  any  inter-AD  routing  proto- 
col should  have  the  potential  of  supporting  very  large  scale  internetworking.  In  an 
internet  of  enormous  size  such  as  DARPA  Internet  it  would  be  unwise  to  design  a 
protocol  that  relied  on  topological  restrictions;  enforcement  would  be  almost  impos- 
sible. Consequently,  one  of  the  design  goals  should  be  allowing  maximum  degree  of 
flexibility  in  regard  to  the  configuration  of  the  internetwork. 

A  traditional  network  hierarchy  includes  long  haul,  regional  and  campus  (stub) 
networks.  However,  there  are  exceptions  to  the  hierarchy  in  the  form  of  lateral 
(bypass)  links.  These  exceptions  to  the  otherwise  regular  topology  are  not  dispensable 
and  must  be  supported,  perhaps  at  the  expense  of  optimality. 
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Protection  of  network  resources 

Many  discussions  of  network  security  are  actually  discussions  of  end-system  pro- 
tection in  a  network  environment  [6,  51,  52,  53].  One  of  our  assumptions  in  the  design 
of  transit  network  controls  is  that  both  stub  and  transit  ADs  have  valuable  network 
resources  that  are  themselves  the  subject  of  policy  [54].  From  this  perspective,  it  is 
imperative  to  eiddress  the  protection  of  network  resource  in  addition  to  end-system 
protection. 

If  control  is  left  to  the  end-systems,  valuable  stub-AD  network  resources  may 
be  consumed  by  unauthorized  traffic.  Rejecting  packets  at  the  end-system  is  too 
late  from  the  perspective  of  network  resource  usage.  Moreover,  unrestricted  network 
access  increases  the  vulnerability  of  ADs  to  denial  of  service  attacks  in  the  form  of 
packet  storms.  Finally,  some  ADs  might  need  to  control  which  routes  are  used  to  and 
from  their  internal  end-systems  due  to  cost  or  security  reasons.  Because  routing  is 
a  network  level  function,  these  controls  must  also  involve  network  level  entities  and 
can  not  be  left  to  transport  session  end-points  [54]. 

2.4.2  Policies 

We  can  find  an  analogy  between  ADs  and  sovereign  countries,  each  with  a 
specific  set  of  foreign  policy  statements  regarding  interaction  with  foreign  entities 
(other  ADs).  For  example,  a  country  may  have  policies  restricting  foreign  visitors 
to  specific  areas  or  restricting  travel  privileges  of  the  local  populace  when  visiting 
foreign  countries.  Countries  may  also  have  specific  policies  pertaining  to  transit 
travelers,  such  as  restricting  entry  on  the  basis  of  the  traveler's  itinerary.  Security 
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policies  regarding  international  travel  can  express  policy  as  to  passport  and  visa 
requirements,  length  of  stay,  etc.  Accounting  or  billing  policies  may  concern,  for 
example,  visa  fees  or  departure  taxes. 

ADs  can  express  similar  policies  regarding  communication  with  external  entities, 
such  as  restricting  internal  systems  available  for  external  access  or  restricting  external 
systems  available  for  internal  access.  Transit  traffic  may  or  may  not  be  allowed,  or  it 
may  be  restricted  to  specific  source  and/or  destination  ADs  or  end-systems.  Policies 
can  also  embody  security  requirements,  such  as  authentication  and  authorization  for 
inter-AD  traffic,  as  well  as  accounting  and  billing  conditions  [55]. 

Network  level  policies  are  primarily  concerned  with  unauthorized  access  to  net- 
work resources,  denial  of  service,  and  inappropriate  accrual  of  communication-related 
charges.  These  threats  can  all  come  about  through  attacks  on  the  authenticity  and 
the  integrity  of  internetwork  packet  traffic.  Some  concerns  are  of  greater  importance 
to  stub  networks  and  others,  to  transit  networks. 

Stub  and  transit  policies 

Due  largely  to  the  nature  of  service  provided,  stub  and  transit  ADs  tend  to 
express  different  policies.  Policies  expressed  by  stub  ADs,  for  the  most  part,  serve  to 
protect  internal  resources  from  external  access,  while  those  expressed  by  transit  ADs 
tend  to  be  cost-related.  Another  way  of  making  this  distinction  is  to  observe  that 
transit  ADs,  by  virtue  of  providing  transit  service,  are  inherently  more  open  than 
their  stub  counterparts.  Furthermore,  subversion  of  transit  AD's  policies  will,  in  the 
worst  case,  result  in  denial  of  service,  whereas  subversion  of  stub  network  polices  can 
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potentially  disrupt  the  end-systems  themselves.  Another  reason  for  separating  the 
respective  policies  is  the  difference  in  accounting  and  billing  requirements.  Stub  ADs 
are  more  likely  to  bundle  communication  costs  into  billing  for  end  services,  if  any 
such  billing  occurs.  Transit  ADs  are  more  likely  to  charge  for  the  communication 
itself.  Finally,  stub  AD  policies  include  route  selection  criteria,  which  dictate  how 
the  AD's  packets  travel  to  their  destinations. 

In  some  respects,  the  requirements  for  transit  policy  enforcement  are  simpler 
than  those  for  stub  policy  enforcement.   However,  several  factors  complicate  the 
implementation  of  the  latter.  First,  in  an  internetwork,  a  packet  may  travel  through 
a  number  of  transit  ADs  on  its  way  to  the  destination.   Consequently,  applicable 
policies  from  all  transit  ADs  must  be  considered  when  a  packet  is  being  sent;  whereas 
for  control  of  stub  resources,  only  the  policies  of  the  two  end-point  ADs  need  to  be 
taken  into  account.  In  addition,  transit  control  has  to  be  reconciled  with  topology 
changes  (routers  or  links  going  down).  If  in  the  middle  of  a  connection  any  component 
of  the  route  becomes  disabled,  an  entirely  different  policy  may  come  into  effect.  Also, 
when  a  transit  AD  decides  to  account  and/or  bill  for  resource  usage,  coordination 
is  required  to  pass  charges  back  to  the  end  points.  Moreover,  stub  route  selection 
criteria  must  be  integrated  with  transit  control  policies  to  determine  the  appropriate 
routes.  These  factors  add  to  the  complexity  of  potential  enforcement  mechanisms. 

Based  in  part  on  the  difference  in  policies,  and  in  part  on  the  functionality 
required  in  any  routing  (i.e.,  transit)  mechanism,  transit  and  stub  AD  mechanisms 
also  differ.  By  analogy  with  international  travel,  in  most  countries  transit  travelers  are 
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set  apairt  from  other  visitors.  They  are  issued  special  transit  visas  and  are  restricted 
in  movement  and  length  of  stay.  I  discuss  transit  mechanisms  further  in  later  sections. 

Policy  attributes 

Network  usage  policies  can  be  based  upon  a  number  of  attributes: 

•  Endpoint  policies  place  restrictions  on  the  source  and/or  destination  of  traffic. 

•  Path  policies  place  restrictions  on  other  ADs  of  the  path  in  addition  to  the 
source  and  destination  ADs. 

•  Security  attributes  express  requirements  for  authentication,  data  integrity, 
replay  detection  and  privacy. 

•  Temporal  parameters  include  restrictions  on  usage  based  on  time  of  day,  day 
of  the  week  or  other  time- related  parameters. 

•  Quality  of  Service  policies  discriminate  according  to  the  service  parameters 
(e.g.,  delay,  throughput)  made  available  to  different  users. 

•  Accounting/Billing  policies  express  conditions  related  to  charging  and  ac- 
counting. 

A  typical  policy  statement  can  be  based  upon  several  policy  attributes.  For 
example,  the  policy  statement,  "transit  voice  traffic  from  ADa  is  accepted  between 
2  and  6  a.m.  with  a  per  packet  charge",  applies  to  transit  traffic  and  combines 
application  protocol,  temporal  and  accounting/billing  attributes.  Further  examples 
of  policy  types  can  be  found  in  RFC  11 25  [55]. 
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2.4.3    Controlling  Transit  Internetwork  Traffic 

There  are  two  basic  approaches  to  controlling  transit  traffic.  In  the  first  part  of 
this  section,  an  approach  based  on  the  extension  of  stub  network  access  control  mech- 
anisms is  discussed  and  its  limitations  are  identified.  Subsequently,  the  alternative 
approaches  based  on  integrating  controls  into  internetwork  routing  are  considered. 

Extending  stub  network  access  controls 

One  potential  method  of  enforcing  transit  policy  enforcement  is  to  extend  exist- 
ing stub  network  access  control  mechanisms  to  the  generalized  internetwork  model. 

Visa  protocols  [29]  were  developed  originally  to  provide  datagram-level  control 
at  AD  boundaries.  The  process  of  establishing  authorization  in  Visa-controlled  tran- 
sit ADs  is  essentially  the  same  as  for  stub  ADs  in  the  Visa  protocol.   The  major 
difference  is  that  the  source  host  must  obtain  a  transit  visa  for  each  transit  AD 
that  requires  one,  in  addition  to  obtaining  a  pair  of  exit/entry  visas  from  ADsrc  and 
ADdst.  In  the  worst  case,  each  transit  AD's  ACS  will  conduct  an  authorization  and 
authentication  procedure  before  issuing  a  transit  visa,  and  each  packet  will  have  to 
carry  a  separate  visa  for  each  intervening  AD.  Of  course,  transit  ADs  may  choose 
to  issue  visas  automatically,  or  not  require  any  visas  at  all  where  transit  traffic  is 
concerned.  Furthermore,  ADs  could  program  their  ACSs  to  obtain  and  issue  transit 
visa-keys  in  advance  of  the  actual  communication.  This  would  reduce  the  setup  delay 
at  connection  establishment  time.  On  the  other  hand,  such  mechanisms  increase  the 
problems  associated  with  visas  expiring  before,  or  while  they  are  in  use. 
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Although  the  extension  of  the  Visa  concept  to  transit  control  is  rather  straight- 
forward, the  approach  does  not  scale  well  to  an  internetwork  where  many  ADs,  both 
stub  and  transit,  want  to  control  traffic  flows.  For  example,  visa  acquisition  and 
route  setup  must  be  repeated  (or  adapted)  each  time  an  involved  visa-router  goes 
down.  Moreover,  a  source  AD  has  no  way  of  determining  if  it  will  be  issued  a  visa 
without  incurring  the  overhead  of  contacting  the  particular  ACS  in  question. 

The  essence  of  the  problem  is  that  transit  control  is  related  to  packet  routing. 
Therefore,  controls  for  transit  should  be  incorporated  into  the  route  calculation  itself, 
not  only  into  the  packet  forwarding  function. 

The  access  control  policy  in  SP3  [56]  is  also  endpoint-oriented.  It  is  concerned 
mainly  with  determining  whether  or  not  two  peers  may  communicate  and  what  type 
of  information  they  may  exchange.  This  and  other  network  access  control  schemes 
such  as  router  packet  filters  [17]  face  the  same  limitation  when  it  comes  to  controlling 
transit  traffic.  That  is,  these  schemes  enforce  controls  on  packet  forwarding  and  do 
not  provide  information  to  the  route  computation. 

In  summary.  Visa  protocols  and  other  network  access  control  mechanisms  are 
best  suited  for  stub  network  control.  Transit  network  control  for  large  internetworks 
is  more  efficiently  achieved  by  integrating  policy  considerations  into  the  route  com- 
putation process. 

Policv  routing 

As  described  earlier,  the  central  goal  of  transit  traffic  control  is  to  allow  ADs  to 
express  and  enforce  policies  regarding  transit  traffic.  Our  discussion  in  the  previous 
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section  demonstrates  that  transit  control  is  intimately  related  to  Inter-AD  Routing. 
An  interdomain  routing  that  incorporates  policy  constraints  is  called  policy  routing 
(PR). 

In  this  section  two  approaches  of  policy  routing  are  summarized.  The  first  is  the 
Border  Gateway  Protocol  (BGP)  [57,  58,  59]  which  is  intended  to  support  a  limited 
notion  of  policy.  The  second  is  the  Inter-Domain  Policy  Routing  (IDPR)  proposal 
designed  to  support  more  general  policies  [48,  49]. 

Policy  routing  operates  at  the  network  layer.  In  both  example  architectures, 
only  border  routers  and  associated  interdomain  route  servers  are  directly  affected  by 
the  presence  of  the  interdomain  routing  protocols.  End-systems  and  interior  routers 
can  continue  employing  whatever  internetworking  protocols  are  desired  within  their 
particular  ADs.  Border  routers  operate  on  behalf  of  the  end-systems.  For  this  reason, 
the  term  source  hereafter  refers  to  the  border  router  in  the  AD  of  the  source  end- 
system. 

Border  Gateway  Protocol.  BGP  is  an  external  gateway  protocol  for  communi- 
cation between  routers  in  different  ADs.  BGP  is  a  replacement  for  the  older  EGP  [50] 
that  was  used  on  the  ARPANET.  BGP  was  first  proposed  in  1989  [49]  and  Version 
3  [58]  and  Version  4  [57]  have  been  developed  so  far.  Its  foremost  goal  is  to  provide 
efficient  and  robust  inter- AD  routing  with  rapid  convergence  and  loop  detection  for 
arbitrary  internetwork  topologies.  In  addition,  it  provides  policy-based  distribution 
of  routing  information.  It  is  aimed  mainly  at  transit  ADs  and  can  interoperate  with 
other  routing  protocols. 
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BGP  is  designed  under  the  following  assumptions: 

1.  Policies  can  he  expressed  using  information  about  the  full  AD  path  that  packets 
will  travel  to  a  destination. 

2.  Transit  policies  apply  uniformly  to  all  endpoints. 

BGP  uses  hop-by-hop  routing  and  a  distance  vector  algorithm  for  the  next  hop 
selection.  One  common  benefit  of  traditional  distance  vector  algorithms  is  the  ability 
to  hide  network  structure.  Neighboring  nodes  exchange  reachability  information  for 
a  specific  destination  in  the  form  of  distance  metrics  corresponding  to  each  next 
hop.  Nodes  do  not  exchange  information  about  subsequent  hops  to  the  destination. 
BGP  augments  this  traditional  approach  by  distributing  full  AD-level  paths.  In 
other  words,  for  each  destination  advertised,  nodes  specify  the  AD-level  path  to  that 
destination.  As  a  result,  BGP  provides  less  information  hiding  in  return  for  the 
ability  to  detect  routing  loops  quickly.  By  using  the  full  AD  path  to  detect  loops 
BGP  avoids  imposing  topological  restrictions  on  AD  interconnection  (such  as  those 
imposed  by  EGP).  In  addition,  AD  path  information  can  be  used  as  a  policy  criterion 
for  route  selection. 

BGP  allows  for  limited  policy-based  route  selection.  Each  AD's  BGP  router  can 
select  its  next  hop  based  on  the  information  provided  in  the  full  AD  path,  in  addition 
to  the  distance  metric.  For  example,  AD  a  can  reject  all  routes  through  ADb-  On 
the  other  hand,  each  AD  must  apply  the  same  route  selection  decision  to  all  packet 
sources,  including  itself.  For  example,  ADa  cannot  reject  all  routes  through  ADb  for 
itself  without  affecting  its  neighbors,  and  vice  versa.  Similarly,  an  AD  can  not  apply 
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one  policy  to  one  neighbor  and  a  second  policy  to  another  neighbor.  Since  BGP  was 
not  intended  to  implement  policies  that  discriminate  between  traffic  end-points  with 
arbitrary  granularity,  the  approach  achieves  its  goals  [60]. 

Each  BGP  router  can  be  configured  according  to  its  AD's  local  policy.  Even 
though  local  policy  is  not  distributed  among  ADs,  it  is  represented  in  a  universal 
policy  language.  A  policy  in  this  language  is  an  expression: 

[Network  —  list,  AD  —  path]  =  preference 

The  semantics  of  a  policy  are  as  follows:  if  a  routing  update  for  a  network  in 
the  Network-list  is  received  via  the  AD-path  and  its  preference  metric  is  higher  than 
that  of  a  path  currently  in  use,  then,  this  update  must  be  redistributed  to  all  ADs. 

Inter-Domain  Policy  Routing.  An  alternative  architecture  for  policy  routing  has 
been  developed  to  support  a  wider  range  of  policies;  the  Inter-Domain  Policy  Routing 
(IDPR)  proposal  allows  stub  and  transit  ADs  to  express  and  exchange  packet  routing 
and  forwarding  policies.  The  most  distinguishing  feature  of  this  approach  is  the  use 
of  AD-level  source  routing.  It  uses  a  Link  State  algorithm  ^  to  compute  source  Policy 
Routes  (PRs)  at  the  granularity  of  ADs.  Each  AD  expresses  its  policies  in  a  standard 
form,  called  Policy  Terms  (PTs)  [49],  and  distributes  them  to  other  ADs.  Each  AD 

''In  a  link-state  protocol  a  router  does  not  exchange  distances  with  its  neighbors.  Instead  each 
router  actively  tests  the  status  of  its  link  to  each  of  its  neighbors,  sends  this  information  to  its  other 
neighbors,  which  then  propagate  it  throughout  the  AD.  Each  router  takes  this  link-state  information 
and  builds  a  complete  routing  table.  Practically,  link-state  protocol  will  always  converge  faster  than 
a  distance- vector  protocol. 
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designates  special  Route  Servers  (RSs)  to  collect  PTs  and  compute  policy  routes  for 
constituent  users.  The  basic  assumptions  of  this  model  are: 

1.  Most  policies  can  be  clajssified  and  expressed  in  a  standard  notation. 

2.  Policies  and  inter-AD  connectivity  change  relatively  slowly. 

3.  End-point  specific  policies  should  be  supported. 

Two  primary  concepts  in  this  proposal  are  Policy  Routes  (PRs)  and  Policy 
Terms  (PTs).  A  PR  is  a  series  of  ADs.  It  is  essentially  an  AD-level  source  route.  In 
other  words,  there  may  be  multiple  physical  realizations  of  a  PR  given  multiple  phys- 
ical connections  between  ADs  and  multiple  intra-AD  routes.  The  actual  selection  of 
a  particular  physical  path  is  done  at  packer  forwarding  time  by  each  intervening  AD 
rather  than  by  the  source  AD  at  route  computation  or  route  selection  time.  This 
lazy  evaluation  provides  for  a  more  adaptive  protocol  and  unrestricted  AD  inter- 
connection. Policy  Terms  (PTs)  are  the  units  of  routing  information  exchanged  by 
communicating  ADs.  Each  PT  represents  a  distinct  policy  of  the  AD  that  expressed 
it. 

Policies  are  expressed  by  source,  destination,  and  transit  ADs.  The  source  AD 
may  select  all  transit  ADs  while  transit  and  destination  ADs  control  which  source 
and  destination  ADs  can  communicate  via  which  directly  connected  ADs.  ADs  run 
link  state  routing  algorithms  to  compute  their  respective  tables  of  PRs.  There  may 
be  multiple  PRs  listed  for  the  same  destination  AD,  each  with  a  different  set  of 
conditions  associated  with  its  use  (e.g.,  quality  of  service,  time-of-day,  or  user  class). 
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Note  that  ADs  (with  the  exception  of  the  source  AD)  do  not  exert  control 
over  the  entire  Policy  Route.  Referring  back  to  our  travel  analogy,  it  is  difficult  to 
enforce  policies  that  are  based  on  information  that  is  not  verifiable  at  the  point  of 
reference.  For  example,  it  is  difficult  to  enforce  a  policy  that  dictates  non-admittance 
to  anyone  who  has  ever  passed  through  country  X,  since  it  is  very  much  dependent  on 
X  stamping  passports  reliably.  In  the  environment  of  interconnected  ADs,  a  transit 
AD  can  verify  the  previous  and  next  hops  because  of  its  direct  connections  and  the 
feasibility  of  employing  pairwise  authentication  with  the  relatively  small  number  of 
neighbors.  Verifying  other  transit  components  of  the  PR  is  difficult,  if  not  impossible. 

Each  AD  has  one  or  more  Route  Server  (RS),  an  entity  that  collects  Policy 
Routing  information  from  other  ADs,  distributes  local  policy  information  to  other 
ADs  and  computes,  as  well  as  issues,  PRs  to  local  end-systems.  Actual  policy  en- 
forcement is  done  at  a  Policy  Gateway  (PG)  which,  in  addition  to  the  usual  task  of 
forwarding  packets,  handles  validation  and  verification  of  the  PRs  attached  to  the 
incoming  packets. 

A  path  is  established  with  the  first  packet  carrying  the  full  PR,  that  is,  the 
complete  sequence  of  ADs  in  the  route  and  applicable  PT  identifiers.  PGs  along  the 
way  make  sure  that  the  PR  agrees  with  the  local  PTs  (through  use  of  templates, 
for  example).  The  result  is  cached  so  that  a  specified  PR  handle  can  be  used  in 
the  future  to  refer  to  the  cached  entry.  Successive  packets  carry  a  PR  handle,  not 
a  full  PR.  Many  transport  level  sessions,  and  even  host-pairs,  may  share  a  single 
PR  if  the  policies  enabling  it  are  not  end-system-specific;  this  reduces  the  average 
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latency  and  router  state  overhead  associated  with  interdomain  communication.  PGs 
use  these  handles  in  the  packets  to  check  for  cache  entries.  PGs  also  may  relate 
return  flow  packets  with  forward  flow.  Given  information  about  the  next  AD  for  a 
particular  packet,  each  PG  selects  the  next  PG  based  on  the  information  exchanged 
in  a  traditional  routing  protocol. 

Comparison  of  approches 

Policy  routing  allows  ADs  to  interconnect  to  the  global  internet  while  still  pro- 
tecting network  resources  from  general,  unconstrained  use.  However,  policy  routing 
mechanisms  do  not  preclude  the  need  for  network  access  controls  in  the  border  routers 
of  ADs  that  wish  to  control  access  to  individual  end-systems. 

One  essential  difference  between  Visa  and  the  policy  routing  approach  is  the 
per  session  setup  overhead.  Transit  Visa  requires  that  a  dialog  transpire  between 
the  source  and  each  transit- Visa  network's  ACS,  and  that  corresponding  key  be  dis- 
tributed. Consequently,  the  initial  setup  delay  grows  in  proportion  to  the  number  of 
transit  networks.  For  short  transactions  such  overhead  is  not  acceptable.  A  PR-based 
approach  such  as  that  in  BGP  or  IDPR  avoids  this  setup  dialog  through  background 
distribution  of  policy  term  information  that  is  used  in  route  computation.  The  work 
that  the  Policy  Routing  protocols  do  to  distribute  policy  terms  and  compute  autho- 
rized routes  must  be  done  at  the  time  of  the  session  setup  in  Visa.  In  particular, 
with  Visa  protocol  this  translates  into  a  reject  packet,  ACS  dialog,  and  visa-key 
grant  message  for  each  AD  in  the  path.  Moreover,  this  assumes  that  the  source 
attempts  communication  over  a  path  for  which  it  has  authorization.  If  there  is  a 
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conflict  with  even  one  transit  AD's  policy,  the  process  must  begin  again.  Policy 
Routing  incorporates  policy  into  the  route  computation  process  in  advance  of  the 
actual  communication,  thereby  avoids  this  problem. 

On  the  other  hand,  the  PR  schemes,  as  described  thus  far,  rely  on  post-facto 
detection  of  abuse  and  in  that  sense,  are  less  secure  than  network  access  controls 
schemes  such  as  Visa  protocols.  In  chapter  5, 1  address  the  integration  of  preventative 
mechanisms  into  policy  routing  to  achieve  secure  control  of  transit  traflSc. 


CHAPTER  3 
PACKET-LEVEL  ACCESS  SECURITY  SCHEME 

3.1  Motivation 

With  increasing  internetwork  applications,  emerging  internetworks  are  frequently 
required  to  connect  administrative  domains  (ADs)  that  may  have  competing  inter- 
ests. In  this  environment,  security  threats  of  unauthorized  accesses  to  the  resources 
axe  very  high.  Therefore,  an  efficient  and  effective  access  control  scheme  is  needed. 

However,  most  work  on  internetwork  security  aims  to  provide  confidentiality  and 
integrity  of  information  in  transit  by  either  inserting  a  security  sublayer  or  modifying 
existing  protocol  layers  to  utilize  existing  cryptographic  tools  [7,  8,  14,  16].  Although 
firewalls  protect  internal  resources  from  unauthorized  accesses  from  outside,  this  can 
only  be  achieved  at  the  expense  of  inflexibility  and  inconveniences  for  the  internal 
users.  On  the  other  hand.  Security  Services  of  OSF's  DCE  [24]  and  ECMA's  SESAME 
[27]  are  rather  complex  and  exclusive  solutions  for  client/server-based  distributed 
systems  and  not  for  immediate  use  in  the  internetwork  environment.  More  specifically 
targeted  work  towards  internetworks  [28,  30]  are  suffer  from  security  vulnerability  and 
excessive  overhead. 

This  led  us  to  develop  a  more  efficient  and  effective  stub-domain  mechanism, 
a  packet-level  access  security  scheme  (PASS)  [61].  PASS  requires  each  organization 


44 


45 


to  control  all  the  exit  and  the  entry  points  of  its  internal  network  to  implement  a 
nondiscretionary  access  control  mechanism  to  isolate  pure-internal  resources  from 
externally  accessible  resources.  PASS  does  not  require  each  AD  to  have  dedicated 
local  access  control  servers.  This  makes  PASS  scheme  more  acceptable  in  many 
situations.  Moreover,  PASS  is  efficient  in  the  sense  that  the  protocol  overhead  is  low 
enough  so  as  not  to  affect  the  configuration  of  existing  higher-layer  protocols  and 
applications. 

The  primary  goal  of  PASS  is  to  allow  an  AD  to  control  communication  between 
its  constituent  end-systems  and  end-systems  in  other  ADs  to  a  specific  system  level. 
This  goal  can  be  achieved  if  the  end-systems  involved  can  be  trusted.  This  trust 
can  only  be  verified  and  maintained  by  strictly  controlling  the  exit  and  entry  of  the 
packets  to  an  AD  since  the  only  information  available  about  a  packet  is  attached  to 
the  packet  in  a  datagram  network.  In  other  words,  a  packet  can  only  leave  the  source 
AD  if 

•  the  source  end-system  has  been  authorized  to  communicate  with  the  corre- 
sponding destination  end-system, 

•  the  packet  is  originated  at  the  source  end-system  within  a  reasonable  time 
interval, 

•  the  packet  is  properly  addressed  for  the  destination  end-system,  and 

•  the  packet  has  not  been  modified  in  transit. 
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Similarly,  a  packet  can  only  enter  the  destination  AD  if  the  conditions  similar 
to  those  mentioned  above  are  met. 

3.2    Network  Environment 

I  assume  that  the  internetwork  closely  follows  the  model  of  the  DARPA  Internet, 
which  is  substantially  similar  to  the  Open  Systems  Interconnection  (OSI)  model.  The 
essential  features  of  the  environment  are  as  follows: 

•  End-systems  are  autonomous  and  cannot  necessarily  be  trusted. 

•  ADs  are  interconnected  with  routers;  between  any  pair  of  end-systems  in  dif- 
ferent ADs  there  are  at  least  two  routers,  one  belonging  to  each  of  the  ADs. 
The  terms  border  router  and  interdomain  router  are  equivalent. 

•  All  information  flows  via  datagram  packets.  A  packet  consists  of  a  header  that 
includes  addressing  and  other  control  information,  and  a  data  segment  that  is 
not  intelligible  to  routers. 

•  A  packet  may  flow  through  several  untrusted  ADs  on  its  way  to  the  destination. 

•  Both  source  and  destination  end-system  addresses  can  be  forged.  It  is  not 
possible  (using  hardware  methods)  to  determine  reliably  which  end-system  ac- 
tually sent  a  packet  or  to  prevent  a  packet  from  being  seen  by  an  unauthorized 
end-system. 

•  Packets  traveling  across  an  internetwork  may  be  lost,  duplicated,  or  re-ordered. 
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•  Successive  packets  between  a  given  end-system  pair  may  travel  along  different 
routes. 

In  addition  to  these,  there  must  exist  a  global  name  service  which,  in  a  secure 
and  reliable  fashion,  provides  a  mapping  from  end-system  network  addresses  to  AD 
identifiers  in  addition  to  the  rather  traditional  mapping  between  end-system  names 
and  addresses.  ITU-T  X.509  [37]  will  provide  this  service  along  with  the  public  key 
certificates  of  principals  involved. 

3.3    Components  of  PASS 

To  achieve  the  goal  of  this  scheme,  several  components  of  PASS  should  work 
together  in  concert  on  a  given  internetwork  environment.  The  following  components 
of  PASS  are  described  in  this  section:  internet  access  control  gateway,  passes,  end- 
systems,  and  certification  authority  (CA). 

3.3.1    Internet  Access  Control  Gateways 

An  internet  access  control  gateway  (lACG)  is  a  border  router  that  uses  the 
PASS  protocol  to  enforce  access  controls.  All  interdomain  connections  must  be  im- 
plemented via  PASS-routers.  Unlike  other  border  routers,  lACG  is  also  responsible 
for  authorization  and  authentication  with  end-systems  in  its  local  AD.  lACGs  are 
trusted  and  assumed  to  defend  against  attempted  abuse  from  external  entities.  This 
assumption  is  critical  since  these  gateways  issue  and  maintain  packet  authentication 
keys. 
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The  choice  of  the  authorization  and  authentication  procedures  used  by  an  lACG 
is  the  decision  of  each  individual  AD.  The  procedure  may  involve  establishing  a  high- 
level  conversation  with  the  end-system,  in  which  a  password,  biographical  data,  or 
other  authenticating  information  is  requested.  The  public  key  based  authentication 
protocol  which  is  used  in  interdomain  authentication  can  also  be  used  in  this  intrado- 
main  case.  Access  control  decisions  may  be  most  appropriately  made  according  to 
group  or  class  affiliation  and  associated  category  sets  that  determine  access  rights. 
The  PASS  scheme  itself  does  not  dictate  or  constrain  any  particular  authorization 
scheme.  Regardless  of  the  approaches  used,  the  PASS  scheme  assumes  only  that  a 
yes/no  decision  is  passed  to  the  PASS  software.  This  dissertation  describes  the  PASS 
interface  to  lACG,  not  the  lACG  design  itself.  Finally,  significant  application-specific 
access  control  is  left  to  the  end-systems  and  applications;  our  scheme  addresses  only 
control  of  access  to  the  hosts  on  a  network. 

The  functions  of  an  lACG  can  be  summarized  as  follows: 

•  On  receipt  of  an  AUTH-REQUEST  packet  from  a  local  end  system,  an  lACG 
authorizes  and  authenticates  the  host. 

•  Performs  interdomain  authentication  with  a  peer  lACG  during  the  pass  request 
procedure  on  behalf  of  an  end-system  in  its  local  AD.  i 

•  Issues  a  new  pass  to  the  peer  gateway. 

•  Forwards  a  new  pass  which  is  granted  by  the  peer  gateway  to  the  initiating 

local  host.  i 
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•  Expires  a  pass  upon  termination  request  by  participant  host  or  gateway,  or 
upon  timeout,  and  notifies  all  parties  involved  -  hosts  and  other  gateways. 

•  Traps  all  packets  and  searches  for  a  pass  in  pass  list  with  source,  destination 
addresses  and  pass  identifier. 

•  Computes  pass  with  the  pass-key  found  and  compares  it  with  the  one  attached 
to  the  packet. 

•  Rejects  a  packet  without  a  valid  pass. 

•  Forwards  packets  bearing  a  valid  pass  through. 

•  Accepts  a  PASS-GRANT  packet  from  the  remote  lACG  and  adds  a  new  pass 
entry  to  the  pass  list. 

•  Issues  a  REVOKE  packet  and  deletes  a  pass  entry  from  the  pass  list. 

•  Upon  pass  expiration,  it  informs  the  peer  lACG  of  the  fact. 

Figure  3.1  shows  a  simplified  state  diagram  for  an  lACG  at  a  session  initiating 
domain. 

3.3.2    Pass  Key 

A  pass  key  is  an  unique  value  assigned  to  a  communication  session  between  a 
pair  of  end-systems  on  different  ADs.  Depending  on  the  signature  method,  it  may 
be  an  encryption  key  (with  DES)  or  a  secret  prefix/suflBx  (with  MD5  [62]).  It  is  used 
to  compute  a  packet  signature,  called  here  as  a  pass,  for  the  traflSc  from  a  source  to 
a  destination  end-system.  Each  packet  that  belongs  to  an  authorized  session  carries 
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Figure  3.1.  A  simplified  state  diagram  for  a  source  lACG 


a  distinct  pass  value  in  the  IP  header  option  field^  [63]  that  is  a  function  of  pass  key 
and  the  packet  contents. 

In  most  types  of  communication,  packets  will  flow  in  both  directions,  so  both 
end-systems  are  both  a  source  and  a  destination  at  the  same  time.  Therefore,  there 
are  two  possibilities  of  key  assignment:  one-way  pass-key  and  two-way  pass-key. 
A  distinct  pass-key  can  be  assigned  to  each  direction  of  communication  after  two 
separate  one-way  authentications.  To  reduce  the  protocol  overhead,  an  AD  can  allow 
its  lACG  to  issue  a  two-way  pass  key  automatically  after  a  mutual  authentication. 
With  current  implementation,  each  direction  of  a  session  is  assigned  a  unique  pass 
key  after  a  successful  mutual  authentication.  This  increases  the  level  of  security 
since  each  destination  lACG  issues  a  pass-key  for  the  inbound  traffic  after  successful 
^Or  in  the  Authentication  Header  with  IPv6 
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authorization  of  the  source  party.  This  scheme  can  be  easily  modified  to  assign  a  two- 
way  pass  key  to  a  session  for  simplicity.  This  requires  an  additional  authorization  for 
the  other  direction  of  traffic. 

Each  host  that  makes  use  of  the  internetwork  communication  maintains  an  active 
pass  list.  Each  entry  in  the  pass  list  consists  of  a  pass,  pass  identifier  to  differentiate 
multiple  sessions  between  the  same  host  pair,  and  the  addresses  of  the  machines 
involved  in  the  session,  and  any  restrictions  that  may  apply  such  as  pass  lifetime. 
lACGs  also  maintain  a  pass  list  to  enforce  access  control  on  the  traffic  flowing  through 
them. 

3.3.3    PASS  End-Svstems 

End-systems  using  PASS  protocol  to  communicate  each  other  are  called  PASS 
end-systems.  Any  PASS  end-system  who  wants  to  communicate  with  end-systems 
outside  of  its  AD  must  obtain  a  pass-key  allowing  its  packets  to  exit  from  the  local 
AD  and  enter  to  the  destination  AD.  In  order  to  obtain  exit  authorization  it  needs 
to  contact  one  of  the  local  lACGs  which  authenticates  its  identity  and  authorizes 
its  access  rights.  The  local  lACG  then  contacts  the  peer  lACG  in  the  destination 
AD  to  request  a  pass-key  for  its  local  end-system.  After  successful  authorization  and 
authentication,  the  remote  lACG  grants  a  pass-key  to  the  local  lACG,  which  in  turn 
forwards  it  to  the  source  end-system. 

Thereafter,  a  pass  (computed  with  the  corresponding  pass-key)  must  be  attached 
to  every  packet  sent  from  the  requesting  end-system  to  the  apparent  destination.  To 
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do  this,  an  end-system  should  have  a  proper  means  for  generating  pass  and  a  secure 
storage  for  active  pass  list. 

An  end-system  does  not  have  to  have  knowledge  of  the  local  lACG's  address; 
this  may  instead  be  supplied  by  the  lACG  when  an  end-system  first  attempt  to 
communicate  across  the  AD  boundary  without  a  proper  pass.  An  end-system  can 
use  an  authentication  scheme  available  locally  or  can  be  authenticated  by  an  lACG 
during  session  initiation  phase  of  the  PASS  protocol. 

3.3.4    Certification  Authorities 

In  the  X.509  directory-authentication  framework,  a  certification  authority  (CA) 
is  an  authority  trusted  by  one  or  more  users  to  create  and  provide  public-key  cer- 
tificates for  them.  The  heart  of  the  X.509  scheme,  which  is  used  during  interdomain 
authentication,  is  the  public-key  certificate  associated  with  each  user.  These  user 
certificates  are  assumed  to  be  created  by  some  trusted  certification  authority  (CA) 
and  placed  in  the  directory  by  the  CA  or  by  the  user.  The  directory  server  itself  is  not 
responsible  for  the  creation  of  public  keys  or  for  the  certification  function;  it  merely 
provides  an  easily  accessible  location  for  users  to  obtain  certificates.  The  public-key 
certificate  includes  the  following  elements: 

•  Version:  differentiates  among  successive  versions  of  the  certificate  format;  the 
default  is  1988. 

•  Serial  number,  an  integer  value,  unique  within  the  issuing  CA,  which  is  unam- 
biguously associated  with  this  certificate. 
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•  Algorithm  identifier,  the  algorithm  used  to  sign  the  certificate,  together  with 
any  associated  parameters. 

•  Issuer,  the  CA  that  created  and  signed  this  certificate. 

•  Period  of  validity,  consisting  of  two  dates:  the  first  and  last  on  which  the 
certificate  valid. 

•  Subject:  the  user  to  whom  this  certificate  refers. 

•  Public-key  information:  the  public  key  of  the  subject,  plus  an  identifier  of  the 
algorithm  for  which  this  key  is  to  be  used. 

•  Signature:  covers  aJl  of  the  other  fields  of  the  certificate,  and  consists  of  a  hash 
code  of  the  other  fields,  encrypted  with  the  CA's  private  key. 

The  CA  signs  the  certificate  with  its  secret  key.  If  the  corresponding  public  key 
is  known  to  a  user,  then  that  user  can  verify  that  a  certificate  signed  by  the  CA  is 
valid.  User  certificates  generated  by  a  CA  have  the  following  characteristics: 

•  Any  user  with  access  to  the  public  key  of  the  CA  can  recover  the  user  public 
key  that  was  certified 

•  No  party  other  than  the  certification  authority  can  modify  the  certificate  with- 
out this  being  detected 

If  all  users  subscribe  to  the  same  CA,  then  there  is  a  common  trust  of  that  CA. 
All  user  certificates  can  be  placed  in  the  directory  for  access  by  all  users.  In  addition, 
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a  user  can  transmit  his  or  her  certificate  directly  to  other  users.  In  either  case,  once 
a  principal  A  is  in  possession  of  the  other  principal  B's  certificate,  B  has  confidence 
that  messages  it  encrypts  with  A's  public  key  will  be  secure  from  eavesdropping  and 
that  messages  signed  with  A's  private  key  are  unforgeable. 

If  there  is  a  large  community  of  users,  it  may  not  be  practical  for  all  users  to 
subscribe  to  the  same  CA  because  it  is  the  CA  that  signs  certificates,  each  participat- 
ing user  must  have  a  copy  of  the  CA's  own  public  key  in  order  to  verify  signatures. 
This  public  key  must  be  provided  to  each  user  in  an  absolutely  secure  (with  respect 
to  integrity  and  authenticity)  way  so  that  the  user  has  confidence  in  the  associated 
certificates.  Thus,  with  many  users,  it  may  be  more  practical  for  there  to  be  a  number 
of  CAs,  each  of  which  securely  provides  its  public  key  to  some  fraction  of  the  users. 
An  example  of  CA  hierarchy  is  described  in  detail  later. 

3.4    Protocol  Description 

PASS  protocol  consists  of  three  phases.  In  the  session  initiation  phase,  an  end- 
system  first  obtains  authorization  for  transferring  packets  to  a  destination  end-system 
outside  of  its  own  AD.  If  successful,  the  local  lACG  requests  pass-key  to  the  lACG 
in  the  destination  AD  and  acquires  it.  In  the  packet  forwarding  phase,  the  pass  key  is 
used  to  generate  a  packet  data  signature  that  is  attached  to  all  packets  belonging  to 
the  authorized  session.  Finally,  the  session  revocation  involves  the  termination  of  a 
pass  either  because  of  normal  expiration  or  by  explicit  revocation.  In  the  remainder 
of  this  section,  each  protocol  phase  is  discussed  in  detail. 
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Figure  3.2.  An  illustration  of  two  communicating  PASS  ADs 

In  this  protocol,  I  assume  a  one-way  communication,  that  is,  an  one-way  trans- 
fer of  packets  from  a  source  end-system  to  a  destination  end-system.  Therefore, 
only  one-way  authentication  is  sufficient  to  do  this.  A  different  pass-key  should  be 
assigned  to  the  other  direction  of  a  communication  through  the  same  steps  of  the 
protocol.  However,  this  protocol  can  be  extended  for  two-way  communications  by 
just  using  a  mutual  authentication  and  a  two-way  pass-key.  Figure  3.2  illustrates  two 
participating  ADs  which  communicate  using  PASS  protocol,  where  Ha  is  the  source 
end-system  and  Hb  is  the  corresponding  destination. 

3.4.1  Notation 

The  following  notation  is  used  throughout  the  description  of  the  protocol: 

•  PassKij  denotes  a  pass-key  shared  by  a  source  end-system  Hi  and  a  destination 
end-system  Hj. 

•  KUi,  KRi  denote  public  and  private  keys  of  principal  i. 

•  EiclData],  DK[Data]  denote  encryption  and  decryption,  respectively,  of  Data 
with  key  K. 
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•  EKRi[Data],  DKUi[Data]  denote  signing  and  verification,  respectively,  of  Data 
using  a  public  key  system. 

•  Fhaah{Data)  is  a  hash  value  of  one-way  hash  function  applied  to  Data. 
3.4.2    Session  Initiation  Phase 

Each  interdomain  communication  between  PASS  end-systems  requires  a  session 
initiation  procedure  which  does  the  following: 

•  Authorization  and  authentication  of  two  communicating  end-systems  by  each 
of  their  local  lACGs. 

•  Issuance  of  a  pass-key  as  a  result  of  successful  authorization  and  authentication. 

•  Distribution  of  the  pass-key  to  all  parties  involved. 
Exit  authorization 

The  protocol  is  put  in  motion  when  an  end-system,  Ha-,  in  ADa  begins  communi- 
cation with  another  end-system,  Hb-,  in  ADi,.  Ha  may  already  know  that  its  intended 
destination  is  in  a  different  AD,  either  because  it  has  previously  communicated  with 
Hb  or  it  may  have  discovered  this  through  some  external  mechanism  (e.g.,  a  name 
server).  In  this  case.  Ha  may  communicate  directly  with  an  lACG  in  its  AD,  lACGa, 
by  sending  an  AUTH-REQUEST  packet.  Otherwise,  since  the  packet  carries  no  pass, 
the  exit  lACG  will  reply  with  a  REJECT  packet  which  notifies  Ha  that  the  intended 
destination  is  non-local,  and  that  it  must  acquire  a  pass  by  first  getting  authorization 
and  authentication  from  a  local  lACG.  Therefore,  these  first  two  packets  can  be  saved 
if  Ha  knows  that  its  intended  destination,  Hb,  is  in  a  different  AD  beforehand. 
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DATA  Ha^IACGa-.   [Ha,  Hb,  Data] 


(3.1) 


REJECT  lACGa^Ha  i  [Ha,Hb,IACGa] 


(3.2) 


Ha  then  sends  an  authorization/authentication  request  packet,  referred  here  as 


AUTH-REQUEST  packet,  to  lACGa- 


AUTH-REQUEST  Ha-^IACGa'.  [Ha,EKR„J^Hb,TS„^]]  (3.3) 


This  message  is  intended  to  establish  the  identity  of  Ha  and  the  authenticity 
and  the  integrity  of  the  message.  This  is  done  by  signing  the  packet  with  the  private 
key  of  Ha-  If  conventional  encryption  is  used,  the  signing  would  be  done  with  the 
secret  key  shared  by  Ha  and  lACGa-  AUTH-REQUEST  packet  also  claims  that  the 
message  was  intended  for  Hb.  On  the  other  hand,  the  timestamp,  TSjja  guarantees 
the  freshness  of  the  message. 

lACGa  now  needs  i^o's  public  key  to  extract  the  contents  of  the  signed  packet. 
It  is  often  the  case  that  lACGa  has  the  public  key  of  Ha  in  its  local  storage  for 
faster  processing.  Otherwise,  lACGa  should  obtain  the  public  key  certificate  which 
contains  the  public  key  of  Ha  from  X.509  directory. 

With  the  successful  extraction  of  packet  contents,  lACGa  checks  TSna-  Other- 
wise (i.e.,  the  packet  has  been  modified  during  transmission),  lACGa  either  discards 
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the  packet  or  sends  a  REJECT  packet  to  Ha  notifying  it  of  the  fact.  lACGa  does 
similar  things  when  TSna  ^^^^       1°°^  normal  to  prevent  replay  attacks  [64]. 

Next,  lACGa  has  to  authorize  communication  between  Ha  and  Hf,.  This  step  is 
dependent  on  the  particular  policy  employed  by  ADa.  For  example,  it  may  involve  a 
higher-level  authentication  dialog  between  lACGa  and  Ha-  The  details  of  this  proce- 
dure are  beyond  the  scope  of  this  paper.  If  the  authorization  fails,  I  ACQ  a  notifies  Ha 
that  it  is  not  allowed  to  communicate  with  Hb.  Otherwise,  lACGa  proceeds  to  finish 
up  the  authentication  either  by  following  the  local  authentication  protocol  available 
or  by  verifying  the  AUTH- REQUEST  packet  using  the  public  key  of  Ha. 

Upon  successful  authentication,  lACGa  sends  PASS-REQUEST  packet  to  the 
destination  AD,  ADb-  This  request  should  be  delivered  to  the  counterpart  lACG, 
lACGb-  lACGa  may  know  the  address  of  lACGb  from  the  previous  communication 
in  which  case  PASS-REQUEST  may  be  sent  directly.  It  could  also  obtain  lACGbS 
address  via  a  name  service  query  [65].  Otherwise,  PASS- REQUEST  packet  is  ad- 
dressed to  the  destination  end-system,  Hb,  and  eventually  it  is  picked  up  by  lACGb 
since  it  does  not  have  proper  pass  on  it. 

PASS-REQUEST  lACGa^Hbi  [IACGa,EKR:^cGa[Ha,Hb,TSa]]  (3.4) 

Again,  this  packet  is  signed  with  lACGa^s  private  key  to  provide  proof  of  au- 
thenticity and  integrity  of  the  message.  Timestamp  TSa  guarantees  the  timeliness 
and  should  be  unique  since  it  is  used  as  a  pass  identifier  later. 
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Entry  authorization 

When  a  PASS-REQUEST  reaches  ADb,  it  is  trapped  by  lACGb  since  it  does  not 
have  proper  pass  on  it.  lACGb  first  verifies  that  Hb  indicated  in  the  PASS-REQUEST 
is  in  fact  an  end-system  in  its  AD.  This  is  necessary  in  order  to  minimize  time  spent  on 
potentially  malformed  PASS-REQUESTs.  Next,  lACGb  authorizes  communication 
between  Ha  and  Hb-  When  it  fails,  the  REJECT  packet  will  be  sent  to  lACGa. 
Otherwise  it  proceeds  to  the  authentication  procedure.  In  order  to  authenticate  its 
contents  by  recomputing  the  signature,  lACGb  needs  the  public  key  of  lACGa-  This 
public  key  is  found  in  the  public  key  certificate  of  lACGa  which  is  obtained  from  the 
X.509  directory  as  a  response  to  the  request  of  lACGb-  In  the  mean  time,  lACGa 
requests  the  public  key  certificate  of  lACGb  to  a  local  X.509  Certification  Authority 
(CA),  CAa,  to  get  the  public  key  of  lACGb-  Both  lACGs  may  look  up  local  storage 
to  find  the  other  lACG's  public  key  used  in  previous  communications. 

Using  the  public  key  of  lACGai  KUjACGai  lACGb  recomputes  the  signature  of 
the  PASS-REQUEST  and  verify  both  its  origin  and  data  integrity.  Both  freshness  and 
uniqueness  of  the  PASS-REQUEST  packet  are  inferred  from  the  enclosed  timestamp, 
TSa  [43,  66]. 

Pass  grant  and  distribution 

After  successful  authentication,  lACGb  issues  a  new  pass  key  in  the  following 
form: 
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PASS-GRANT  :  lACGb  ^  lACGa  : 
EKRj^cadHa.  ^6,  Alg,  LT,  EKUj^.^AEKRj^cadTSa,  PassKab]]]  (3.5) 

A  PASS- GRANT  packet  includes  the  source  and  destination  end-system  ad- 
dresses, Ha  and  Hi,,  respectively,  that  are  authorized  to  use  this  pass.  In  other 
words,  this  states  that  the  pass  key  has  been  issued  by  Hb  and  is  being  used  for  the 
packets  destined  for  Hb  from  Ha-  PASS  routers  lACGa  and  lACGb  use  these  end- 
system  addresses  to  locate  the  appropriate  pass-key  when  they  associate  incoming 
packets  with  a  particular  communication  session. 

The  timestamp  TSa  is  used  here  as  an  identifier  of  the  pass  key  which  is  assigned 
to  a  pair  of  end-systems.  Ha  and  Hb.  This  value  should  be  unique  and  unused  before. 
In  that  sense,  it  is  used  here  as  a  nonce  [67]. 

LT  is  the  lifetime  of  a  pass-key  to  be  used  to  expire  the  pass-key  when  the  given 
condition  is  met.  A  pass-key  can  be  made  obsolete  at  a  specific  system  time  or  after 
some  specific  amount  of  time  elapsed.  A  maximum  number  of  packets  transmitted 
or  a  maximum  amount  of  data  transferred  can  also  be  used  as  a  LT. 

PassKab  is  a  pass-key  granted  by  lACGb  to  be  used  to  compute  packet  signa- 
tures for  the  traffic  destined  for  Hb  from  Ha-  Depending  on  the  signature  method, 
which  is  specified  in  Alg  field,  PassKab  may  be  either  a  secret  key  of  an  encryption 
system  such  as  DES  or  a  secret  prefix/suffix  for  a  message  digest  scheme  such  as 
MD4  or  MD5. 
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To  achieve  the  confidentiality  of  the  pass-key  during  distribution,  it  is  encrypted 
with  lACGaS  public  key,  which  allows  only  lACGa  to  decrypt  it.  Note  that  the  pass- 
key is  signed  by  lACGb  before  it  is  encrypted.  This  is  to  guarantee  the  integrity  and 
authenticity  of  the  key  and  prevent  the  possible  modification  or  fabrication  attack 
[68]. 

When  lACGa  receives  a  PASS-GRANT  packet,  it  first  verifies  that  Ha,  Hb  and 
TSa  are  indeed  the  same  values  that  were  sent  in  the  PASS-REQUEST  packet.  It 
then  verifies  the  PASS-REQUEST  packet  with  the  public  key  of  lACGb,  KUiacg^- 
Finally,  it  decrypts  and  stores  the  pass-key. 

Next,  lACGa  may  reply  with  ACK  packet  which  notifies  lACGb  that  the  PASS- 
GRANT  packet  has  arrived  safely  and  it  successfully  has  decrypted  PassKab- 

ACK  lACGa^IACGb-.  [IACGa,Epa,,KjIACGb,TSa]]  (3.6) 

ACK  packet  may  be  skipped  for  brevity  even  though  it  makes  the  interdomain 
authentication  more  complete. 

In  the  meantime,  both  lACGa  and  lACGb  create  a  new  entry  in  their  pass-table 
and  lACGa  forwards  the  pass-key  to  Ha  by  sending  PASS-FORWARD  packet. 


PASS-FORWARD  :  lACGa  ^  Ha  : 
[lACGa,  EKR.^caAHa,  Hb,  TSa,  Alg,  LT,  EKu^^[EKR,^^aa[TSH.,  PassKabMS.l) 
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This  packet  is  signed  with  lACGaS  private  key  in  order  to  be  verified  by  Ha  with 
lACGaS  public  key.  The  pass-key  is  encrypted  with  HaS  public  key.  This  prevents 
any  other  principal  in  the  network  from  decrypting  and  acquiring  the  pass-key. 

3.4.3    Packet  Forwarding  Phase 

When  the  setup  phase  is  completed,  Ha  can  begin  communication.  Each  packet 
that  Ha  sends  to  Hb  has  to  be  accompanied  by  a  pass.  Since  there  are  possibilities 
that  more  than  one  communication  sessions  are  outstanding  between  Ha  and  Hi,,  a 
pass  identifier  should  be  included  in  those  packets.  In  this  scheme,  TSa  is  used  for 
this  purpose.  With  it,  the  PASS  routers  can  successfully  identify  an  entry  in  their 
pass  table. 

A  pass  is  computed  as: 

PASS  =  Fhash{[Header,  Data],  PassKab) 

where,  Fhash  is  the  signature  function  determined  by  the  Alg  field  agreed  on 
during  the  session  initiation  phase. 

The  resulting  data  packet  has  the  following  form  which  is  also  shown  in  Fig- 
ure 3.3  with  IP  version  4: 


DATA-PACKET  Ha  ^  H^  :   [Header,  PassID,  Pass,  Data]  (3.8) 
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Figure  3.3.  IP  Version  4  PASS  data  packet  format 
Exiting  source  AD 

When  a  packet  with  a  pass  arrives  at  lACGa-,  it  has  to  be  checked  to  show 
authorization  to  leave  its  local  AD,  ADa^  as  well  as  authenticity  of  its  contents. 
lACGa  first  looks  up  its  peiss-table  with  the  source,  destination  addresses  and  pass- 
key identifier  supplied  by  the  packet.  Successful  look-up  indicates  the  existence  of  exit 
authorization  by  lACGa-  Next,  I  ACQ  a  verifies  the  packet  signature  by  re-computing 
the  packet  signature  and  comparing  it  to  the  pass  attached  to  the  packet.  If  the  two 
values  match,  lACGa  can  safely  conclude  that  packet  contents  are  authentic.  The 
packet  is  now  forwarded  to  the  destination  AD  through  the  internetwork. 
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Entering  destination  AD 

The  operations  performed  by  lACGb  on  any  incoming  data  packet  are  exactly 
the  same  as  those  of  lACGaS;  it  checks  authorization  by  indexing  its  pass-table  with 
the  source  address,  destination  address  and  pass  identifier,  then  re-computes  the 
signature  to  verify  the  authenticity  of  the  packet  contents.  A  successfully  checked 
packet  is  delivered  to  the  destination  end-system, 

3.4.4    Session  Revocation 

A  pass  may  be  revoked  for  a  couple  of  reasons:  first,  a  normal  expiration,  which 
occurs  when  the  Life  Time  condition  is  met,  and  secondly,  an  explicit  revocation  by 
an  lACG.  In  the  first  PASS-router  simply  deletes  the  corresponding  entry 

from  its  pass-table.  When  a  packet  bearing  a  pass  computed  using  an  expired  pass 
arrives  at  the  PASS-router,  it  is  promptly  discarded  since  the  table  look-up  fails.  In 
the  second  case,  an  lACG  may  decide  for  some  reason  that  a  certain  pass  is  no  longer 
trusted  and  sends  a  REVOKE  packet  to  the  appropriate  PASS-router.  The  following 
shows  an  example  of  REVOKE  packet  issued  by  lACGb  and  sent  to  lACGa-  This 
is  further  explained  in  section  3.5.1. 

REVOKE  lACGb^  lACGa  i  EKRi^^a,[Ha,Hb,TSa,Cause]  (3.9) 

This  concludes  the  description  of  the  PASS  protocol.  An  illustration  of  the 
protocol  is  shown  in  Figure  3.4.  A  dotted  arrow  from  lACGa  to  Hb  in  the  figure  tells 
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ADa 


ADb 


Figure  3.4.  An  example  of  PASS  scheme 

that  the  DATA  packet  is  destined  to  Hb  from  Ha  and  trapped  by  lACGa-  C.REQ 
represents  the  request  for  a  public-key  certificate  to  a  local  certification  authority. 
C.IACG-A  represents  the  public-key  certificate  of  /ACGa- 

3.5    Review  of  the  Protocol 

This  section  discusses  several  issues  leading  to  the  design  of  the  PASS  protocol, 
specifically  in  Internet  environment.  It  also  analyzes  some  security  aspects  of  the 
protocol  before  assessing  its  cost. 

3.5.1    Exception  Handling 

There  are  two  situations  when  a  pass-key  becomes  invalid  in  normal  circum- 
stance: i)  when  the  time  limit  is  exceeded,  and  ii)  when  a  pass-key  is  revoked  explic- 
itly. There  should  be  a  proper  mechanism  to  handle  these  situations  appropriately. 


66 


Expiration  of  pass-key 

LT  is  the  lifetime  of  a  pass-key  to  be  used  to  expire  the  pass-key  when  the  given 
condition  is  met.  The  simplest  method  is  by  way  of  timeouts,  that  is,  an  explicit 
time  limit  is  negotiated  at  setup  time  and  a  pass-key  is  invalidated  when  the  time 
limit  is  exceeded.  A  source  host  should  invalidate  the  expired  pass-key  and  should 
initiate  a  new  session  with  the  destination  by  first  removing  the  entry  from  its  pass 
list.  lACG  should  also  remove  the  expired  pass-key  from  its  pass  list  and  reject  any 
incoming  packets  with  the  expired  pass  identifier.  While  this  is  adequate  for  some 
types  of  connections,  provisions  for  other  methods  of  pass-key  expiration  may  be 
necessary.  These  include  limits  on  inactive  periods,  number  of  packets  and  bulk  data 
transferred.  Unfortunately,  expiration  based  on  limits  other  than  just  simple  timeouts 
is  not  possible  without  maintaining  states  in  lACGs.  In  order  to  expire  pass-keys 
according  to  any  of  the  above  criteria  requires  that  an  lACG  maintain  running  tally 
of  packets,  data  bytes  or  the  time  of  last  packet  arrival  on  a  per  pass-key  basis. 

Revocation 

Pass-key  termination  by  explicit  request  from  an  lACG  should  be  viewed  as  more 
of  exception  than  the  norm  as,  ordinarily,  pass-keys  are  terminated  by  exceeding  some 
limit  negotiated  at  the  time  of  issuance.  An  explicit  pass-key  revocation  can  happen 
when  an  lACG  decides  for  some  reason  (in  circumstances  where  there  is  suspicion  of 
a  pass-key's  compromise)  that  a  certain  pass-key  is  no  longer  trusted.  A  REVOKE 
packet  is  sent  to  the  counterpart  lACG  in  this  case  and  the  entry  should  be  removed 
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from  both  of  the  pass-key  lists.  Thereafter,  both  lACGs  have  to  ensure  that  no  more 
packet  traffic  belonging  to  the  revoked  pass-key  connection  passes  through. 

3.5.2    Design  Issues  in  Internet  Environment 

There  are  several  design  issues  which  are  related  to  the  Internet  environment: 
packet  formats  of  PASS-IP  with  current  and  next  version  of  IP  standards,  coverage 
of  packet  signature,  and  datagram  fragmentation. 

PASS  packet  format 

PASS  data  packet  format  with  current  IP  (Version  4)  standard  is  shown  in 
Figure  3.3.  Pass-ID  and  pass  are  stored  in  IP  option  field.  Pass-ID  takes  32  to  64 
bits  depending  on  the  granularity  of  the  timestamp,  and  pass  takes  either  64  bits 
with  DES  or  128  bits  with  MD5.  Total  packet  length  overhead  will  be  160  bits  per 
packet  when  a  32  bit  timestamp  and  the  MD5  algorithm  are  used. 

There  are  two  specific  headers  that  are  used  to  provide  security  services  in 
IPv6  [69]:  the  IP  authentication  header  (AH)  [70]  and  the  IP  encapsulating  security 
payload  header  [71].  The  IP  Authentication  Header,  which  is  used  to  implement  PASS 
scheme,  is  designed  to  provide  integrity  and  authentication  without  confidentiality 
to  IP  datagrams.  The  lack  of  confidentiality  ensures  that  implementations  of  the 
Authentication  Header  will  be  widely  available  on  the  Internet,  even  in  locations 
where  the  export,  import,  or  use  of  encryption  to  provide  confidentiality  is  regulated. 
The  Authentication  Header  has  an  authentication  data  field  which  can  contain  a 
variable  number  of  32-bit  words.  This  field  is  used  to  contain  pass  and  pass  identifier 
as  shown  in  Figure  3.5. 
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Figure  3.5.  IP  Version  6  authentication  header  containing  pass 

As  shown  in  example  IP  datagram  in  Figure  3.5,  the  AH  may  appear  after  any 
other  headers  that  axe  examined  at  each  hop,  and  before  any  other  headers  which 
are  not  examined  at  an  intermediate  hop. 

Coverage  of  packet  signatures 

A  typical  network-layer  header  contains  addressing  information  such  as  source 
and  destination  end-system  addresses,  packet  sequence  number,  packet  length  and 
other  fields  as  the  IP  datagram  header  shown  in  Figure  3.3.  Any  header  field  not 
covered  by  the  packet  signature  leaves  a  potential  covert  channel,  since  an  intruder 
could  trap  a  valid  packet,  change  the  unchecked  field,  and  forward  the  modified  copy 
without  raising  suspicion.    We  could  protect  against  this  by  including  the  entire 
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network-layer  header  under  the  packet  signature,  but  in  most  internetworking  pro- 
tocols there  are  some  header  fields  (e.g.,  header  checksum  and  time-to-live  (TTL) 
field)  that  are  modified  by  the  intermediate  routers,  and  hence  cannot  be  included  in 
the  signature.  Therefore,  these  fields  should  be  masked  when  the  packet  signature  is 
calculated. 

Another  issue  has  to  do  with  the  addressing  information  in  the  network  header. 
Recall  that  pass-keys  are  issued  on  the  basis  of  the  source  and  destination  end-system 
addresses.  As  described  in  previous  section,  each  PASS  data  packet  carries  a  pass 
identifier.  This  identifier  is  stored  alongside  the  two  end-system  addresses  in  pass- 
tables  of  both  lACGs.  Since  an  lACG  still  has  to  consult  its  pass-table  to  look  up 
the  pass-key,  it  can  (inexpensively)  verify  the  Ha,  Hi,  addresses  as  well.  Therefore,  it 
can  be  argued  that  end-system  addresses  and  other  information  (e.g.,  type-of-service, 
transport  protocol,  etc.)  that  is  stored  in  the  pass-table  entry  does  not  need  to  be 
protected  by  the  packet  signature. 

Fragmentation 

In  a  number  of  internetworking  protocols  (e.g.,  IP)  a  router  may  have  to  frag- 
ment a  packet  if  it  cannot  be  transmitted  in  a  single  unit.  Even  though  fragmentation 
is  not  a  unique  problem  with  PASS  protocol,  data  signatures  complicate  the  use  of 
fragmentation  since  the  fragments  must  appear  to  have  been  signed  by  Hare,  but  the 
signatures  would  have  to  be  computed  by  the  fragmenting  router.  But  with  public- 
key  signatures  like  PASS,  this  is  impossible,  since  only  the  originating  end-system 
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can  compute  the  signature.  Fragmentation  is  at  best  a  necessary  evil  [72];  it  is  al- 
most always  better  to  set  packet  sizes  at  Hsrc  ,  to  make  the  best  possible  use  of  the 
available  bandwidth  and  to  provide  acknowledgments  for  each  transmission  unit. 

Although  methods  have  been  proposed  for  accommodating  fragmentation  while 
preserving  data  signatures  [73] ,  it  is  always  better  for  the  source  end-system  to  avoid 
sending  packets  that  will  have  to  be  fragmented  since  the  overhead  incurred  by  those 
methods  axe  not  trivial.  One  way  of  preventing  fragmentation  is  to  utilize  one  of  the 
Internet  Control  Message  Protocol  (ICMP)  messages  [20].  In  other  words,  ICMP  Un- 
reachable/Fragmentation Required  error  message  can  be  used  to  find  out  the  smallest 
maximum  transmission  unit  (MTU)  of  the  communication  path.  This  ICMP  Un- 
reachable/Fragmentation Required  error  occurs  when  a  router  receives  a  datagram 
that  requires  fragmentation,  but  the  don't  fragment  (DF)  flag  is  turned  on  in  the 
IP  header.  What  we'll  do  is  to  send  packets  with  the  DF  bit  set.  The  size  of  the 
first  packet  we  send  will  equal  the  MTU  of  the  outgoing  interface,  and  whenever  we 
receive  an  ICMP  Unreachable/Fragmentation  Required  error  we'll  reduce  the  size  of 
the  packet  to  the  next  smallest  MTU  defined  in  IP  standard  [74]. 

This  can  be  done  before  actual  exchange  of  PASS  packets  to  decide  the  path 
MTU  to  the  destination  to  avoid  fragmentation.  Maintaining  known  values  in  local 
storage  will  reduce  the  communication  overhead. 

3.6    Overhead  Analvsis 

In  this  section,  I  address  the  impact  of  PASS  protocol  on  the  participating 
entities.  The  overhead  can  be  considered  in  two  different  aspects:  one  for  systems 
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and  the  other  for  network.  Comparison  with  other  schemes  is  provided  at  the  end, 
too. 

3.6.1    System  Overhead 

At  the  system  level,  overheads  are  associated  with  the  additional  storage  require- 
ment for  the  PASS  software  codes  and  related  parameters  .  The  overheads  related 
to  the  storage  of  software  codes  vary  according  to  the  type  of  internetwork  entity 
(an  end-system  or  an  access  control  gateway)  and  to  the  programming  paradigms 
employed  in  the  implementation.  These  topics  are  beyond  the  scope  of  this  paper 
and  are  not  discussed  further. 

On  the  other  hand,  maintaining  pass-tables  demands  additional  storage  in  lACGs 
and  end-systems.  Each  lACG  keeps  valid  pass-list  which  at  minimum  consists  of 
source  end-system  address,  destination  address,  pass  identifier,  pass-key,  lifetime, 
and  signing  algorithm.  Due  to  the  limited  availability  of  memory  in  lACG,  it  is 
required  to  keep  the  size  of  the  pass-list  as  small  as  possible.  This  in  turn  requires 
an  efficient  maintenance  of  pass-list  by  removing  invalid  pass  entry  from  the  list  in 
a  timely  manner.  This  depends  on  the  efficiency  of  the  pass  revocation  mechanism. 
Additional  information  such  as  the  arrival  time  of  the  last  valid  packet  might  be 
needed  to  monitor  the  activities  of  communication  sessions  for  detecting  idle  ones. 

An  end-system  must  also  keep  a  list  of  active  passes.  This  pass-list  is  essentially 
the  same  as  the  lACG's  pass-list.  lACGs  and  end-systems  may  need  to  save  public- 
key  certificates  of  peer  entities  in  local  and  remote  ADs  for  faster  access  of  public 
keys  of  them. 
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3.6.2    Network  Overhead 
Session  initiation 

The  number  of  additional  packets  required  for  establishing  an  external  session 
between  Ha  and  Hh  can  be  traced  from  the  sequence  of  events  explained  in  previous 
section.  It  shows  that  there  are  10  extra  packets  required  before  Ha  is  allowed  to  go 
into  the  packet  forwarding  phase.  The  first  two  packets,  DATA  and  REJECT  packet, 
can  be  skipped  if  the  source  end-system  knows  that  the  destination  end-system  is  in 
remote  AD  and  it  has  the  address  of  local  lACG,  lACGa-  Moreover,  four  packets 
involved  in  getting  public-key  certificates  can  also  be  saved  if  both  lACGs  find  each 
other's  public-key  certificates  in  their  local  cache.  Therefore,  only  four  additional 
packets  are  needed  in  session  initiation  phase  in  the  best  case. 

Packet  forwarding 

Extra  packets  are  generated  only  when  there  is  a  failure  in  matching  the  pass 
of  a  pax:ket  transmitted  between  two  peer  entities.  One  extra  packet  is  generated 
if  the  pass  of  a  packet  from  Ha  does  not  match  that  generated  in  lACGa-  Two 
extra  packets  will  be  generated  if  the  pass  of  a  packet  from  Ha  does  not  match  that 
generated  in  lACGb-  Other  overhead  in  this  phase  include  the  additional  fields  in 
data  packets,  table  look-ups  in  lACGs,  and  pass  computation  in  end-systems  and 
lACGs.  The  pass  identifier  is  32-bit  quantity  which  is  typical  for  a  timestamp  in 
internet  protocols.  The  size  of  the  pass  depends  on  the  signature  method  agreed  by 
Algor  field  in  PASS-GRANT  packet.  For  now,  it  is  either  64  bit  DES  key  or  128  bits 
for  MD5  secret  prefix/suffix. 
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3.6.3    Comparison  with  Other  Schemes 

First,  the  number  of  extra  packets  generated  for  each  external  session  in  PASS 
scheme,  which  is  at  most  10,  is  substantially  smaller  than  the  other  two  schemes. 

The  author  of  the  VISA  scheme  illustrated  the  visa  acquisition  phase  for  a  pair- 
wise  connection  with  an  example  and  concluded:  'For  the  illustration  given  above,  a 
minimum  of  15  extra  packets  are  generated  before  the  first  user  packet  gets  through, 
not  including  the  packets  that  comprise  the  authorization/authentication  conversa- 
tions between  hosts  and  ACSs.  Note  that  all  of  these  control  packets  will  be  of 
minimal  length.'  That  is,  this  scheme  may  introduce  well  over  20  extra  packets  in 
session  initiation  phase 

With  Iqbal's  scheme,  there  are  21  extra  packets  required  before  the  local  host  was 
allowed  to  go  into  the  packet  control  mode  to  transport  packets  to  the  remote  network. 
Moreover,  this  number  of  extra  packets  is  derived  with  the  assumption  that  the  transit 
network  gateways  do  not  enforce  the  access  control  procedures.  Obviously,  if  the 
number  of  interconnected  networks  increases  and  the  access  control  procedures  are 
implemented  in  each  of  the  transit  networks,  the  overhead  will  increase  dramatically. 


CHAPTER  4 

INTER-DOMAIN  AUTHENTICATION  WITHOUT  AN  ARBITER 

4.1  Motivation 

Most  of  existing  interdomain  (or  inter-realm)  authentication  protocols  assume 
the  existence  of  a  trusted  third  party  as  an  arbiter  between  two  authenticating  prin- 
cipals [31,  33,  34,  46].  That  is,  they  assume  there  is  a  trusted  Authentication  Server 
which  shares  a  unique  master  key  with  each  of  the  principals.  The  AS  is  capable 
of  producing  good  session  keys  and  sending  them  securely  on  the  requests  of  prin- 
cipals. This  assumption  simplifies  the  interdomain  authentication  problem  into  a 
intra-domain  authentication. 

Other  interdomain  authentication  protocols  are  either  based  on  a  proxy  (or  del- 
egation) concept  or  using  hierarchical  authentication.  The  former  achieves  the  inter- 
domain authentication  through  a  chain  of  trust  between  authentication  servers.  Any 
broken  link  on  the  chain  might  annihilate  the  service.  The  latter  approach  suggests 
a  hierarchy  of  access  control  servers  which  can  perform  interdomain  authentication 
through  cascaded  authentications  at  multiple  levels  [46].  However,  it  is  not  always 
reasonable  to  assume  the  existence  of  a  trusted  authentication  server  between  any 
two  ADs  in  the  internet  environment.  More  often,  there  is  no  trusted  third  party 
between  ADs  which  need  to  authenticate  each  other  in  internetworks. 
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The  interdomain  authentication  protocol  presented  here  does  not  require  any 
trusted  third  party  in  between.  This  interdomain  authentication  protocol,  which  is 
essential  in  interdomain  access  control  schemes,  is  based  on  a  public  key  encryption 
system.  Public  keys  of  peer  principals  are  provided  by  ISO  standard  9594-8/ITU-T 
X.509  Directory  Authentication  Service  [37].  This  removes  the  need  for  a  globally- 
trusted  authentication  server  (AS)  which  is  not  quite  realistic  in  internetwork  envi- 
ronments. This  also  alleviates  the  security  threats  found  in  Iqbal's  scheme  [30]  where 
RSA  private  keys  should  be  shared  between  peer  communicating  entities. 

Some  of  the  important  design  principles  which  differentiate  interdomain  authen- 
tication from  intra-domain  authentication  are  listed  below: 

•  The  message  complexity  and  encryption  overhead  should  be  reduced  as  much 
as  possible  so  that  it  is  feasible  to  implement  in  interdomain  communication. 

•  The  use  of  timestamps,  although  effective  in  reducing  the  message  complexity, 
should  be  used  carefully  in  an  interdomain  authentication,  since  the  existence 
of  proper  clock  synchronization  among  multiple  machines  is  much  more  difficult 
to  guarantee  if  the  machines  reside  in  different  administrative  domains. 

•  Interdomain  authentication  should  be  transparent  to  principals.  That  is,  the 
mechanisms  designed  for  interdomain  authentication  should  not  interfere  with 
the  existing  intra-domain  authentication  mechanisms  at  local  machines.  Any 
addition  or  modification  of  features  for  interdomain  authentication  should  only 
affect  the  involved  parties  such  as  gateways. 
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In  the  next  section,  several  ongoing  efforts  on  providing  public-key  certificate 
infrastructures  are  introduced.  The  descriptions  of  ITU-T  X.509  directory  authen- 
tication service  and  a  new  interdomain  authentication  protocol  based  on  the  service 
are  given  in  the  following  sections. 

4.2    Public-Key  Certificate  Infrastructure 

When  using  public  key  digital  signature  authentications  each  entity  requires 
a  public  key  and  a  private  key.  The  public-key  certificate  is  an  essential  part  of 
a  digital  signature  authentication  mechanism.  Certificates  bind  a  specific  entity's 
identity  (be  it  host,  network,  user,  or  application)  to  its  public  keys  and  possibly 
other  security- related  information  such  as  privileges,  clearances,  and  compartments. 
Authentication  based  on  digital  signatures  requires  a  certificate  authority  to  create, 
to  sign  and  properly  to  distribute  certificates  [75]. 

4.2.1    Certificate  Authorities 

Certificates  require  an  infrastructure  for  generation,  verification,  management 
and  distribution.  The  Internet  Policy  Registration  Authority  (IPRA)  [76]  has  been  es- 
tablished to  direct  this  infrastructure  for  the  Internet  Engineering  Task  Force  (IETF). 
The  IPRA  certifies  Policy  Certification  Authorities  (PCA).  PCAs  control  Certificate 
Authorities  (CA)  which  certify  users  and  subordinate  entities.  Current  certificate  re- 
lated work  includes  the  Domain  Name  System  (DNS)  Security  Extensions  [77]  which 
will  provide  signed  entity  keys  in  the  DNS.  The  Public  Key  Infrastucture  (PKIX) 
working  group  is  specifying  an  Internet  profile  for  X.509  certificates.  There  is  also 
work  going  on  in  industry  to  develop  X.500  Directory  Services  which  would  provide 
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X.509  certificates  to  users.  The  U.S.  Post  Office  is  developing  a  certificate  authority 
hierarchy.  The  National  Institute  of  Standards  and  Technology  (NIST)  Public  Key 
Infrastructure  Working  Group  has  also  been  doing  work  in  this  area.  The  Depart- 
ment of  Defence  (DOD)  Multi  Level  Information  System  Security  Initiative  (MISSI) 
program  has  begun  deploying  a  certificate  infrastructure  for  the  U.S.  Government. 
Alternatively,  if  no  infrastructure  exists,  the  Pretty  Good  Privacy  (PGP)  Web  of 
Trust  certificates  can  be  used  to  provide  user  authentication  and  privacy  in  a  com- 
munity of  users  who  know  and  trust  each  other. 

4.2.2    X-509  Directory  Authentication  Service 

ITU-T  recommendation  X.509  is  a  part  of  the  X.500  series  of  recommendations 
that  defines  a  directory  service.  The  directory  is,  in  effect,  a  server  or  distributed  set 
of  servers  that  maintains  a  database  of  information  about  principals.  The  information 
includes  a  mapping  from  user  name  to  network  address,  as  well  as  other  attributes 
and  information  about  the  users.  X.509  defines  a  framework  for  the  provision  of 
authentication  services  by  the  X.500  directory  to  its  users.  The  directory  may  serve 
as  a  repository  of  public-key  certificates  of  the  type  discussed  below.  Each  certificate 
contains  the  public  key  of  a  user  and  is  signed  with  the  private  key  of  a  trusted 
certification  authority. 

Public-key  certificate 

The  heart  of  the  X.509  scheme  is  the  public-key  certificate  associated  with  each 
user.  These  user  certificates  are  assumed  to  be  created  by  some  trusted  certification 
authority  (CA)  and  placed  in  the  directory  by  the  CA  or  by  the  user.  The  directory 
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server  itself  is  not  responsible  for  the  creation  of  public  keys  or  for  the  certification 
function;  it  merely  provides  an  easily  accessible  location  for  users  to  obtain  certifi- 
cates. 

The  standard  uses  the  following  notation  to  define  a  certificate: 

Y  «A»=Y{V,SN,AI,CA,Ta,A,Ap} 

where,  F  <<  A  >>  represents  the  certificate  of  an  user  A  issued  by  a  certification 
authority  Y.  Y{I}  represents  the  signing  of  /  by  F,  which  consists  of  I  with  an 
enciphered  hash  code  appended.  The  constituents  V,SN,AI,CA,Ta,A,  and  Ap 
represent  a  version  number,  serial  number,  algorithm  identifier,  issuer  CA,  period 
of  validity,  user  identifier,  and  user's  public  key,  respectively.  The  CA  signs  the 
certificate  with  its  private  key.  If  the  matching  public  key  is  known  to  a  user,  then 
the  user  can  verify  that  a  certificate  signed  by  the  CA  is  valid. 

Certificate  authority 

Because  certificates  are  unforgeable,  they  can  be  placed  in  a  directory  without 
the  need  for  the  directory  to  make  special  efforts  to  protect  them.  If  all  users  subscribe 
to  the  same  CA,  then  there  is  a  common  trust  of  that  CA.  All  user  certificates  can 
be  placed  in  the  directory  for  access  by  all  users.  In  addition,  a  user  can  transmit 
his  or  her  certificate  directly  to  other  users.  In  either  case,  once  a  principal  B  is  in 
possession  of  the  other  principal  A's  certificate,  B  has  confidence  that  messages  it 
encrypts  with  A's  public  key  will  be  secure  from  eavesdropping  and  that  messages 
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signed  with  A's  private  key  are  unforgeable.  If  there  is  a  large  community  of  users, 
it  may  not  be  practical  for  all  users  to  subscribe  to  the  same  CA;  because  it  is  the 
CA  that  signs  certificates,  each  participating  user  must  have  a  copy  of  the  CA's  own 
public  key  in  order  to  verify  signatures.  This  public  key  must  be  provided  to  each 
user  in  an  absolutely  secure  (with  respect  to  integrity  and  authenticity)  way  so  that 
the  user  has  confidence  in  the  associated  certificates.  Thus,  with  many  users,  it  may 
be  more  practical  to  have  a  number  of  CAs,  each  of  which  securely  provides  its  public 
key  to  some  fraction  of  the  users. 

Now  suppose  that  A  has  obtained  a  certificate  from  a  certification  authority  Xi 
and  B  has  obtained  a  certificate  from  a  CA  X2.  If  A  does  not  securely  know  the 
public  key  of  X2,  then  B's  certificate,  issued  by  X2  is  useless  to  A.  A  can  read  B^s 
certificate,  but  A  cannot  verify  the  signature.  However,  if  the  two  CAs  have  securely 
exchanged  their  own  public  keys,  the  following  procedure  will  enable  A  to  obtain  5's 
public  key. 

1.  A  obtains,  from  the  directory,  the  certificate  of  X2  signed  by  Xi.  Because  A 
securely  knows  Xi's  public  key,  A  can  obtain  A'2's  public  key  from  its  certificate 
and  verify  it  by  means  of  Xi 's  signature  on  the  certificate. 

2.  A  then  goes  back  to  the  directory  and  obtains  the  certificate  of  B  signed  by 
X2.  Because  A  now  has  a  trusted  copy  of  X2^s  public  key,  A  can  verify  the 
signature  and  securely  obtain  5's  public  key 
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A  has  used  a  chain  of  certificates  to  obtain  5's  public  key.  In  the  notation  of 
X.509,  this  chain  is  expressed  as: 

Xi  «      »  X2  «  B  » 

In  the  same  fashion,  B  can  obtain  A's  public  key  with  the  reverse  chain: 

X2  «  Xi  »  Xi  «  A  » 

This  scheme  need  not  be  limited  to  a  chain  of  two  certificates.  An  arbitrarily 
long  path  of  CAs  can  be  followed  to  produce  a  chain.  A  chain  with  N  elements  would 
be  expressed  as: 

Xi  «  X2  »  X2  «  Xz  »  ...  «  Xn  »  Xn  «  B  » 

In  this  case,  each  pair  of  CAs  in  the  chain  {Xi,Xi+i)  must  have  created  certifi- 
cates for  each  other.  All  these  certificates  of  CAs  need  to  appear  in  the  directory, 
and  the  user  needs  to  know  how  they  are  linked  in  order  to  follow  a  path  to  another 
user's  public-key  certificate.  X.509  suggests  that  CAs  be  arranged  in  a  hierarchy,  so 
that  navigation  is  straightforward. 

Certificate  authoritv  hierarchy 

Figure  4.1  is  an  example  of  such  a  hierarchy.  The  connected  circles  indicate  the 
hierarchical  relationship  among  the  CAs;  the  associated  boxes  indicate  certificates 
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u«v» 
v«u» 


A 

B 

c 

X«A» 

X«C» 

Z«B» 

Figure  4.1.  X.509  CA  hierarchy:  A  hypothetical  example 
maintained  in  the  directory  for  each  CA  entry.  The  directory  entry  for  CA  X  includes 
two  types  of  certificates: 

•  Forward  certificates:  certificates  of  X  generated  by  other  CAs 

•  Reverse  certificates:  certificates  generated  by  X  that  are  the  certificates  of  other 
CAs 

In  this  example,  user  A  can  acquire  the  following  certificates  from  the  directory 
to  establish  a  certification  path  to  B: 


X  «W  »W  «V  »V  «Y  »Y  «  Z  »  Z  «  B  » 


When  A  has  obtained  these  certificates,  it  can  unwrap  the  certification  path  in 
sequence  to  recover  a  trusted  copy  of  B's  public  key.  Using  this  public  key,  A  can 
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send  encrypted  messages  to  B.  U  A  wishes  to  receive  encrypted  messages  back  from 
B,  or  to  sign  messages  sent  to  B,  then  B  will  require  A's  public  key,  which  can  be 
obtained  from  the  following  certification  path: 

Z  «Y  »Y  «V  »V  «W  »W  «X  »  X  «  A» 

B  can  obtain  this  set  of  certificates  from  the  directory,  or  A  can  provide  them 
as  part  of  its  initial  message  to  B. 

Recall  from  the  previous  description  that  each  certificate  includes  a  period  of 
validity,  much  like  a  credit  card.  Typically,  a  new  certificate  is  issued  just  before  the 
expiration  of  the  old  one.  In  addition,  it  may  be  desirable  on  occasion  to  revoke  a 
certificate  before  it  expires  for  one  of  the  following  reasons: 

1.  The  user's  secret  key  is  assumed  to  have  been  compromised. 

2.  The  user  is  no  longer  certified  by  this  CA. 

3.  The  CA's  secret  key  is  assumed  to  have  been  compromised. 

Each  CA  must  maintain  a  list  consisting  of  all  revoked  but  not  expired  certifi- 
cates issued  by  that  CA,  including  both  those  issued  to  users  and  to  other  CAs.  These 
lists  should  also  be  posted  on  the  directory.  Each  certificate  revocation  list  posted  to 
the  directory  is  signed  by  the  issuer  and  consists  of  the  issuer's  name,  the  date  the 
list  was  created,  and  an  entry  for  each  revoked  certificate.  Each  entry  consists  of  the 
serial  number  of  a  certificate  and  revocation  date  for  that  certificate.  When  a  user 
receives  a  certificate  in  a  message,  the  user  must  determine  whether  the  certificate 
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has  been  revoked.  The  user  could  check  the  directory  each  time  a  certificate  is  re- 
ceived. To  avoid  the  delays  (and  possible  costs)  associated  with  directory  searches,  it 
is  likely  that  the  user  would  maintain  a  local  cache  of  certificates  and  lists  of  revoked 
certificates. 

4.3    A  Secure  and  Efficient  Interdomain  Authentication  Protocol 

Central  to  the  problem  of  authenticated  key  exchange  are  two  issues:  confiden- 
tiality and  timeliness.  To  prevent  masquerade  and  to  prevent  compromise  of  session 
keys,  essential  identification  and  session  key  information  must  be  communicated  in 
encrypted  form.  This  requires  the  prior  existence  of  secret  or  public  keys  that  can  be 
used  for  this  purpose. 

This  protocol  is  based  on  the  assumption  that  the  two  parties  know  each  other's 
public  key,  either  by  obtaining  each  other's  public-key  certificates  from  an  X.509 
directory  or  because  the  certificate  is  found  in  the  local  cache  from  some  previous 
use.  The  second  issue,  timeliness,  is  important  because  of  the  threat  of  message 
replays.  Such  replays,  at  worst,  can  allow  an  opponent  to  compromise  a  session 
key  or  successfully  impersonate  another  party.  At  minimum,  a  successful  replay  can 
disrupt  operations  by  presenting  parties  with  messages  that  appear  genuine  but  are 
not. 

4.3.1  Notation 

The  following  notation  is  used  throughout  the  description  of  the  protocol.  The 
notations  here  are  used  to  maintain  the  conformity  to  the  BAN  logic  [42,  47]. 

•  A{I}  denotes  signing  of  /  with  A's  private  key. 
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Message  1 
Message  2 


Message  3 


Figure  4.2.  An  interdomain  authentication  protocol 

•  {I}k  denotes  encryption  of  /  with  a  key  K.  K  can  be  either  a  public  key  in 
public  key  system  or  a  secret  key  with  a  conventional  encryption  system. 

•  Kab  denotes  a  shared  key  between  principals  A  and  B. 

4.3.2    The  Protocol 

The  message  flow  of  the  protocol  is  shown  in  Figure  4.2  and  the  details  of  the 
messages  are  shown  as  follows: 

Message  1   A^B:   A,  A{B,  TSa} 

Message  2  B A  :  B,  B{A,TSb,{B{TSa,  Kab}}KA 

Messages  A B  :  A,{B,TSb}K,, 


where,  ^4(7}  represents  information  signed  by  encrypting  it  with  A's  private  key. 
U}Ka  represents  information  encrypted  by  A's  public  key.  Principal  A  initiates  the 
authentication  by  sending  B  a  timestamp  TSa  along  with  the  identity  of  itself  and 
that  of  the  desired  destination  principal.  The  destination  address  and  a  timestamp 
are  signed  with  A's  private  key  to  provide  the  authentication  of  this  message. 
After  B  receives  this  message,  it  generates  a  session  key  Kab  and  sends  it  to  A  along 
with  the  timestamp  sent  by  A  and  a  new  timestamp  TSb-  The  session  key  is  signed 
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first  with  the  private  key  of  B  and  then  encrypted  with  the  public  key  of  A.  A  then 
gets  the  session  key  by  first  decrypting  it  with  its  private  key  and  then  with  5's 
public  key.  Finally,  A  sends  an  acknowledgment  packet  which  is  encrypted  with  the 
session  key,  Kab- 

4.3.3    Informal  Analysis 

The  first  message  establishes: 

•  the  identity  of  A, 

•  that  the  message  was  generated  by  A, 

•  that  the  message  was  intended  for  B, 

•  the  integrity  of  the  message,  and 

•  the  freshness  of  the  message 

At  a  minimum,  the  message  includes  a  timestamp  TSa  and  the  identity  of  B,  and  is 
signed  with  A's  private  key.  The  timestamp  consists  of  an  optional  generation  time 
and  an  expiration  time.  This  prevents  delayed  delivery  of  messages.  A  nonce,  Na, 
can  be  used  to  detect  replay  attacks.  The  nonce  value  must  be  unique  within  the 
expiration  time  of  the  message.  Thus,  B  can  store  the  nonce  until  it  expires  and 
reject  any  new  messages  with  the  same  nonce.  Here,  TSa  can  be  considered  as  a 
nonce  which  is  useful  when  it  is  difficult  or  impossible  to  have  synchronized  system 
clocks.  B  now  can  safely  believe  that  this  message  is  generated  by  A  since  only  A 
has  the  private  key  to  sign  this  message. 
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The  second  message  establishes  the  following: 

•  the  identity  of  B, 

•  that  the  reply  message  was  generated  by  B, 

•  that  the  message  was  intended  for  A 

•  the  integrity  of  the  reply  message, 

•  the  freshness  of  the  reply  message,  and 

•  the  confidentiality  of  the  session  key,  Kab 

The  session  key,  Kat,  is  first  signed  with  5's  private  key  and  then  encrypted  with  A's 
public  key.  The  former  provides  the  authenticity  of  the  session  key  while  the  latter 
guarantees  the  confidentiality  of  the  key  since  only  A  can  decrypt  it.  The  order  of 
signing  and  encryption  is  important  here,  as  will  be  further  explained  later. 

The  last  message  confirms  B  that  A  has  received  the  session  key  safely.  The 
timestamp  TSb  provides  the  freshness  proof  with  B. 

4.4    Formal  Protocol  Analysis  Using  BAN  Logic 

In  this  section,  the  proposed  protocol  is  analyzed  by  using  BAN  Logic,  BAN 
Logic  is  a  formal  protocol  verification  method  to  assure  the  correctness  of  an  authen- 
tication protocol.  Each  message  of  the  protocol  is  converted  into  the  idealized  form 
according  to  the  method  suggested  by  BAN  logic  [47]  and  is  shown  below: 
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Message  1   A  ^  B  :  A{TSa] 

Message  2   B -*  A  :  B{TSb,{B{TSa,A^^''B}}Kj 
Messages   A^B:   {B,TSb,A^^'  B}k,, 

The  idealized  messages  correspond  quite  closely  to  the  messages  shown  in  the  original 
protocol.  The  cleartext  communication  has  been  removed  throughout  since  it  pro- 
vides no  guarantees  of  any  kind.  The  sender  information  from  the  first  two  messages 
has  been  removed  since  it  does  not  contribute  to  the  beliefs  of  the  recipient.  As  usual, 
the  timestamps  TSa  and  TSb  are  viewed  simply  as  nonces  in  the  idealized  protocol. 
Message  2  may  tell  A,  who  knows  the  key  K~^,  that  Kab  is  a  key  to  communicate 
with  B. 

The  initial  assumptions  of  the  protocol  in  BAN  logic  notation  are: 

Key  l.A         A  2.B  ^'S  B 

3.A        B  LB  A 

f>.A^{B^  A^  B)  G.B^A^'B 

Freshness   l.A  ^  ^{TSa)  2.B  ^  ^{TSb) 

The  first  four  assumptions  in  the  key  group  tells  that  each  principal  knows  its 
own  secret  key  and  the  other's  public  key.  The  next  two  show  that  B  has  invented  a 
new  key,  and  that  A  trusts  B  to  invent  the  good  keys.  The  two  assumptions  in  the 
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freshness  group  tell  that  each  principal  can  verify  and  thus  believes  the  freshness  of 
timestamp  it  generated. 

The  formal  proof  of  the  protocol  using  the  postulates  of  BAN  logic  is  presented 
as  follows.  First,  A  sends  a  signed  timestamp  to  B  and  B  sees  it: 

B  <  A{TSa} 

This  and  the  fourth  key  assumption  gives  the  following  through  the  message-meaning 
rules: 

B^A\^TSa 

And  B  can  decrypt  this  message  since  it  has  A's  public  key. 

B<TSa 

Similarly,  the  message  2  gives: 
A<TSb 

A<{B{TS.,A'h'B}}K^ 
A  can  decrypt  the  last  component  shown  above,  and  we  get: 
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A  <  B{TSa,  A  B} 

This  and  the  third  key  assumption  give  the  following  through  the  message-meaning 
rules: 

A]^  B  \^  A^'  B 

From  the  freshness  assumption,  A  knows  that  TSa  is  fresh.  This  guarantees  the 
freshness  of  the  shared  key  A  <4''  B.  This  freshness  and  the  belief  established  just 
before  give  the  following  via  the  nonce-verification  rule: 

A^B^A^'B 

Finally,  this  and  the  assumption  of  5's  jurisdiction  over  A  ^  B  together  give: 
A^A^^'  B 

Message  3  gives  the  following  through  the  freshness  and  nonce-verification  rules: 


B^A^A^^'B 
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In  conclusion,  the  final  beliefs  of  both  principals  achieved  by  this  protocol  are: 

A^A'h"  B  B^A^'  B 

A^B^A^'B  B^A^A^^'B 

which  are  exactly  the  formalized  goals  of  authentication  for  all  authentication  pro- 
tocols as  recommended  by  the  authors  of  BAN  Logic.  These  goals  are  achieved  with 
only  three  messages. 

Note  that  the  session  key  in  the  second  message  is  signed  first  with  B^s  private 
key  before  it  is  encrypted.  That  is  because  although  Kab  has  been  transferred  in  a 
signed  message,  there  is  no  evidence  to  suggest  that  the  sender  is  actually  aware  of  the 
data  that  he  sent  in  the  private  part  of  the  message.  This  corresponds  to  a  scenario 
where  some  third  party  intercepts  a  message  and  removes  the  existing  signature  while 
adding  his  own,  blindly  copying  the  encrypted  section  within  the  signed  message.  In 
other  words,  the  last  part  of  beliefs  cannot  be  established  without  signing  before  the 
encryption  of  the  session  key  [68]. 

4.5    Preventing  Replav  Attacks 

Since  the  destination  address  B  in  the  last  message  guarantees  the  uniqueness 
of  his  own  timestamp  TSb,  he  can  be  sure  that  this  message  is  linked  uniquely  to 
this  instance  of  the  protocol  in  a  timely  fashion.  Consider  an  attack  scenario  with  a 
version  of  our  authentication  protocol  which  does  not  include  B  in  the  last  message 
as  ITU-T  X.509  three  way  protocol  [37].  This  version  of  the  protocol  just  sign  the 
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Figure  4.3.  A  scenario  of  a  replay  attack 


last  message  with  A^s  private  key  instead  of  encrypting  it  with  the  session  key.  One 
might  hope  that  the  use  of  TSb  would  be  sufficient  to  link  the  third  message  to  the 
first,  since  TSb  links  the  last  two  messages  and  TSa  links  the  first  two  messages.  The 
error  here  is  that  TSb  alone  does  not  link  the  last  two  messages,  and  this  allows  an 
intruder  C  to  replay  one  of  i4's  old  messages. 

The  following  concrete  exchange  which  is  also  shown  in  Figure  4.3  illustrates  the 
flaw.  The  timestamp  TSb  is  not  secret,  and  there  is  nothing  to  prevent  C  from  using 
the  same  value  in  an  instance  of  the  protocol  between  A  and  C.  If  C  is  able  to  cause 
A  to  attempt  authentication  with  C  at  the  required  time,  the  following  sequence  of 
messages  can  result.  The  intruder  first  contacts  B: 


Message  1   C     B  :   A,  A{B,  TSa} 


This  is  an  old  message  originally  sent  by  A.  Remember  that  B  is  not  presumed  to 
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check  the  timestamp  TSa  as  it  is  used  here  as  a  nonce,  and  so,  will  not  discover  the 
replay  of  A's  original  message. 

Message  2  B  ^  C  :  B,B{A,TSi„{B{TSa,Kab]}Ka] 

B  replies  as  though  the  message  came  from  A,  and  provides  a  new  timestamp,  TSi,. 
At  this  point,  C  causes  A  to  initiate  authentication  with  C,  by  whatever  means. 

Messages   A^C:  A,A{C,TS',] 

A  has  now  initiated  authentication  with  C.  The  exact  content  of  the  message  is 
immaterial.  C  replies  to  A^  providing  the  timestamp  TSi,,  which  was  originally 
provided  by  B. 

Message  4  C  ^  A:  C,C{A,TS,,{C{TS',,K,,})k^ 

A  replies  to  C,  signing  the  exact  message  needed  for  C  to  convince  B  that  the  first 
message  was  sent  recently  by  A,  and  is  not  a  replay  of  an  old  message. 


Messages   A  ^  C  :  A,A{TSb] 
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This  message  is  now  being  sent  to  5  by  C  without  any  problem. 

Message  6  C B  :  A,A{TSb} 

The  three-way  authentication  protocol  suggested  in  ITU-T  X.509  service  [37]  has  this 
security  flaw.  This  kind  of  replay  attack  is  not  possible  with  the  proposed  interdomain 
authentication  protocol. 

4.6    Variations  of  the  Protocol 

Some  minor  modifications  with  the  original  protocol  might  reduce  the  effort  of 
encryption  without  affecting  the  security  of  it.  In  other  words,  the  second  message 
of  the  original  protocol  can  be  rewritten  as: 

Message  2a  B  ^  A  :  B,A,TSb,{B{TSaJ<ab}}K. 

In  addition  to  this,  we  might  have  situations  in  which  we  need  to  modify  the  protocol 
for  different  communication  requirements:  when  one-way  authentication  or  one-way 
pass  is  needed 

4.6.1    One-Wav  Authentication 

PASS  protocol  described  in  previous  section  is  based  on  an  one-way  interdo- 
main authentication.  That  is,  the  source  lACG  identifies  itself  as  a  claimant  to  the 
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destination  lACG  and  the  destination  lACG  verifies  the  identity  of  it.  With  success- 
ful authentication,  the  verifier  issues  a  pass-key  and  distributes  it  to  the  claimant  for 
later  use.  This  pass-key  is  an  one-way  pass  which  authorizes  a  communication  session 
between  a  specific  source  and  a  specific  destination  end-system.  The  other  direction 
of  traffic  between  the  same  pair  should  be  authorized  separately  by  following  the 
PASS  protocol. 

The  following  protocol  is  intended  for  one-way  authentication  and  signed  secure 
distribution  of  pass-key  which  is  used  to  generate  pass  stamps  in  packet  forwarding 
phase  of  PASS  protocol. 

Message  1   A  ^  B  :   A,  A{B,  TSa} 
Message  2  B  ^  A  :  B,{B{TSa,Kab}}K. 

As  in  the  original  protocol,  the  first  message  establishes  the  following: 

•  the  identity  of  A,  and  that  the  message  was  generated  by  A, 

•  that  the  message  was  intended  for  B, 

•  the  integrity  and  freshness  of  the  message 

The  PASS-REQUEST  message  described  in  previous  section  acts  as  the  first 
message  in  this  authentication  protocol.  In  the  PASS-REQUEST  message,  lACGa 
and  lACGb  replace  A  and  B  in  messages  shown  above,  respectively.  The  only  differ- 
ence is  the  destination  in  the  PASS-REQUEST  message  is  not  lACGt,  but  Hb.  This 
is  because  lACGa  may  not  know  the  address  of  lACGb  when  it  sends  this  message. 
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This  does  not  make  any  difference  since  the  message  is  supposed  to  be  trapped  by 
lACGb  for  the  lack  of  a  proper  pass-stamp  on  it. 

This  message  thus  permits  both  parties  in  a  communication  to  verify  the  identity 
of  the  other.  This  reply  message  includes  the  timestamp  sent  from  A,  TSa  and  an 
encrypted  pass-key  Kab-  Kab  is  is  encrypted  with  A's  public  key  and  sent  to  A  to  be 
used  in  generating  pass  stamps  for  the  packets  destined  to  B  from  A.  This  second 
message  is  implemented  as  the  PASS-GRANT  message  in  PASS  protocol. 

If  B  wants  to  send  a  packet  io  A,  B  should  go  through  the  similar  steps  to  be 
authorized  to  do  so. 

4.6.2    Mutual  Authentication  with  One- Way  Pass 

The  following  protocol  is  intended  for  mutual  authentication  and  signed  secure 
exchange  of  pass  key.  That  is,  a  two-way  authentication  is  performed  between  two 
principals  at  once  and  each  direction  of  the  communication  session  is  assigned  a 
distinct  pass-key. 

Message!   A^B:  A,A{B,TSa,{A{Kba]]K,} 
Message  2  B-^A  :  B,B{A,TSb,{B{TSa,Kba,K,b}}KA 
Messages   A B  :  A,{B,TSb}K^, 

Here,  Kab  represents  the  pass-key  issued  by  B  and  assigned  for  the  traffic  flowing 
from  A  to  B.  Kba  is  for  the  other  direction  of  the  traffic  between  A  and  B.  The  first 
message  establishes  the  identity  of  A,  that  the  message  was  generated  by  A,  that  the 
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message  was  intended  for  5,  the  integrity  and  freshness  of  the  message,  and  finally 
the  secrecy  of  the  pass-key,  Kba. 

Similarly,  the  second  message  establishes  the  identity  of  B,  that  the  reply  mes- 
sage was  generated  by  B,  that  the  message  was  intended  for  A.  It  also  assures  the 
integrity  and  freshness  of  the  reply  message,  and  the  privacy  of  the  pass-key,  Kab-  It 
also  confirms  A  that  B  received  the  session  key  Ki,a  safely.  The  last  message  confirms 
B  that  A  has  received  the  key  safely.  This  protocol  could  be  further  simplified  by 
omitting  this  message. 


CHAPTER  5 

SECURE  CONTROL  OF  TRANSIT  INTERNETWORK  TRAFFIC 

5.1  Motivation 

Chapter  2  discussed  the  problem  of  simply  extending  stub  access  control  schemes 
to  transit  cases;  although  it  is  straightforward,  the  approach  does  not  scale  well  to  an 
internetwork  where  many  ADs,  both  stub  and  transit,  want  to  control  traffic  flows. 
For  example,  visa  acquisition  and  route  setup  must  be  repeated  (or  adapted)  each 
time  an  involved  visa-router  goes  down.  Moreover,  a  source  AD  has  no  way  of  de- 
termining if  it  will  be  issued  a  visa  without  incurring  the  overhead  of  contacting  the 
particular  ACS  in  question.  This  is  because  transit  control  is  related  to  packet  rout- 
ing. Therefore,  controls  for  transit  should  be  incorporated  into  the  route  calculation 
itself,  not  only  into  the  packet  forwarding  function. 

On  the  other  hand,  policy  routing  allows  ADs  to  interconnect  to  the  global  inter- 
net while  still  protecting  network  resources  from  general  unconstrained  use.  However, 
policy  routing  mechanisms  do  not  preclude  the  need  for  network  access  controls  in 
the  border  routers  of  ADs  that  wish  to  control  access  to  individual  end-systems. 
Moreover,  the  PR  schemes,  as  described  thus  far,  rely  on  post-facto  detection  of 
abuse,  and  are  in  that  sense  less  secure  than  straightforward  network  access  control 
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schemes.  Most  of  work  in  policy-beised  protocol  development  is  being  conducted  with 
such  environments  in  mind  [49,  59,  60]. 

This  chapter  addresses  environments  where  post  facto  detection  is  not  adequate 
or  possible  in  a  timely  manner.  In  particular,  it  addresses  the  design  and  costs  (i.e., 
performance  and  manageability)  of  incorporating  more  defensive,  preventive  security 
measures  into  IDPR  protocol  for  controlling  internetwork  traffic. 

5.2    Security  Issues  in  Transit  Control 

This  section  identifies  the  potential  security  threats  faced  by  the  PR  schemes 
and  describes  the  mechanisms  needed  in  a  secure  protocol. 

5.2.1    Security  Threats 

The  threats  to  the  security  of  PR  protocols  are  due  to  the  possible  attacks  on 
the  routing  information  and  data  packets.  An  intruder  may  distribute  false  routing 
information  in  order  to  disrupt  communication  or  to  eavesdrop  on  communication. 
The  former  can  be  achieved  by  creating  routing  loops  and  the  latter  by  rerouting 
traffic  to  a  specific  location. 

Attacks  on  control  and/or  data  packets  can  lead  to  unauthorized  resource  usage, 
unauthorized  communication,  and  inappropriate  accrual  of  charges.  These  attacks 
can  be  further  classified  as: 

•  Falsification  of  control  information:  this  affects  the  route  setup  and  packet 
forwarding  parameters  in  addition  to  the  usual  network  layer  information  such 
as  source  and  destination  addresses,  data  size. 
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•  Falsification  of  data:  the  data  portion  of  a  packet  can  be  modified  or  replaced 
by  an  intruder. 

•  Replay:  previously-recorded  legitimate  packets  can  be  replayed  by  an  intruder. 
Two  sources  of  replay  are  of  equal  concern:  accidental  replay  due  to  the  stut- 
tering of  a  misbehaving  machine,  and  malicious  replay  due  to  a  misbehaving 
person  attempting  a  denial  of  service  attack. 

In  IDPR,  these  security  attacks  can  take  the  form  of  distributing  falsified  Policy 
Terms  causing  invalid  Policy  Routes  to  be  computed.  An  intruder  can  also  intercept 
a  legitimate  PR  header  and  substitute  an  invalid  Charge  Code.  Hereafter,  the  IDPR 
proposal  is  used  as  the  foundation  for  our  protocol  design.  It  provides  the  finest- 
grained  control  through  the  use  of  AD-level  source  routes.  Moreover,  this  greater 
control  provides  a  wider  range  of  possible  attacks.  Hence,  security  issues  that  arise 
in  this  proposal  form  a  superset  of  those  in  the  BGP  approach. 

5.2.2    Cryptographic  Tools 

As  discussed  in  previous  section,  we  are  concerned  primarily  with  data  integrity 
and  source  authenticity  of  exchanged  messages.  Confidentiality  of  user  data  is  not 
a  unique  problem  to  the  transit  access  control  case  and  therefore,  left  to  end-to- 
end  mechanisms  [6].  Confidentiality  of  routing  control  information  is  a  less  general 
requirement  than  integrity  and  authenticity,  and  is  discussed  briefly. 
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Signed  one-way  hash  functions 

One  of  the  efficient  and  effective  ways  of  providing  data  integrity  and  source 
authenticity  is  to  use  a  signed  one-way  hash  function.  That  is,  for  each  message  we 
compute  Fhash{Data)  where  Data  includes  the  invariant  portions  of  the  packet  header 
(i.e.,  those  fields  that  do  not  change  en  route  between  source  and  destination)  and  the 
packet  data.  The  resulting  value  is  then  signed.  If  a  public  key  scheme  is  used  then  the 
value  is  signed  with  the  private  key  of  the  originator.  The  resulting  value  is  referred  to 
as  the  packet  signature.  Anyone  needing  to  verify  the  message  integrity  and  sender 
authenticity  computes  FhashiData),  decrypts  the  packet  signature  with  the  public 
key  of  the  sender,  and  compares  the  two  values.  If  a  conventional  encryption  scheme 
is  used,  Fhash{Data)  is  encrypted  and  decrypted  with  the  secret  key  to  produce  and 
verify  the  signature,  respectively. 

The  scheme  is  efficient  because  only  Fhash{Data)  needs  to  be  encrypted,  and 
computing  the  one-way  hash  function  is  faster  than  encrypting.  As  a  result,  the 
difference  in  processing  overhead  between  public  key  and  conventional  encryption 
schemes  is  reduced. 

Throughout  the  reminder  of  this  section,  Rivest's  Message  Digest  algorithm 
MD5  [62]  is  used  as  an  example  one-way  hash  function.  MD5  has  an  additional 
calculation  step  and  hence  somewhat  slower  to  execute  than  MD4.  Rivest  felt  that 
the  added  complexity  was  justified  by  the  increased  level  of  security  afforded.  In 
addition  to  being  the  fastest  method  available  currently,  it  is  also  being  used  as 
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a  basic  data  integrity  mechanism  in  several  other  contexts,  most  notably,  Privacy- 
Enhanced  Electronic  Mail  [76,  78,  79,  80].  Processing  speed  for  MD5  implementations 
on  a  33  MHz  intel  80486  machine  is  about  174  megabytes/second  [81].  For  an  1000 
byte  packet,  this  translates  into  an  overhead  of  5.7/is  per  packet. 

Encryption  svstems 

In  general,  conventional  encryption  is  not  well-suited  for  an  environment  such 
as  Link  State  routing  where  routing  updates  are  broadcasted  to  a  large  number  of 
recipients.  Sharing  a  single  common  key  amongst  all  nodes  affords  little  protection, 
while  distributing  pairwise  keys  to  each  AD-pair  is  impractical. 

The  alternative  is  to  use  public  key  encryption  for  the  distribution  of  PTs.  At 
first  glance,  this  might  appear  problematic  because  current  public  key  technology 
is  still  inferior  in  terms  of  performance.^  However,  if  we  are  concerned  only  with 
the  integrity  and  authenticity  of  routing  information  then  the  signature  mechanisms 
described  in  above  can  be  used  with  little  performance  impact.  Moreover,  one  of  the 
central  assumptions  in  the  IDPR  proposal  is  that  policies  change  relatively  slowly. 
Any  added  processing  time  associated  with  public  key  encryption  is  counter-balanced 
by  the  ubiquity  and  efficiency  of  being  able  to  generate  a  single  unforgeable  packet 
signature  which  can  be  authenticated  by  any  recipient. 

BGP  has  a  similar  requirement  for  authenticity  and  integrity  (and,  possibly, 
confidentiality)  of  routing  information.  However,  because  it  is  a  distance  vector 
protocol,  routing  updates  are  distributed  to  a  much  smaller  number  of  destinations, 

'In  software,  DES  is  about  100  times  faster  than  RSA.  These  numbers  may  change  slightly  as 
technology  changes,  but  RSA  will  never  approach  the  speed  of  a  symmetric  algorithm  [81]. 
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that  is,  only  the  direct  neighbors  of  the  originating  router.  At  the  same  time,  each 
message  is  considerably  larger  (equivalent  of  a  complete  routing  table)  than  in  the  link 
state  algorithm.  Conventional  encryption  may  be  more  appropriate  in  this  case  since 
the  number  of  keys  needed  per  policy  router  will  be  small,  hence,  easy  to  manage. 
Moreover,  if  confidentiality  is  desired,  conventional  encryption  will  save  considerably 
on  processing  time. 

5.3    Description  of  Security  Mechanisms 

This  section  describes  the  security  mechanisms  which  are  added  to  IDPR  pro- 
tocol in  order  to  make  it  a  secure  transit  control  scheme.  Security  mechanisms  are 
described  for  each  of  three  phases  of  IDPR:  Policy  Term  distribution,  route  setup, 
and  packet  forwarding. 

The  following  notation  is  used  throughout  the  description  of  the  protocol: 

« 

•  II  is  the  concatenation  operator  as  in  A"  ||  Y. 

•  N  denotes  the  length  of  a  PR,  that  is,  the  number  of  ADs  in  a  PR. 

•  ADi{0  <  i  <  N)  denotes  the  i-th  AD  in  a  PR,  ADo  =  AD„c,  and  ADn  = 
ADdsf 

•  Kij  denotes  a  secret  key  shared  by  ADi  and  ADj. 

•  Kaig  denotes  a  secret  key  used  for  computing  data  signatures. 

•  KUi,  KRi  denote  public  (encryption)  and  private  (decryption)  keys  of  ADi. 
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•  Efc[Data],  DK[Data]  denote  encryption  and  decryption,  respectively,  of  Data 
with  key  K. 

•  EKRi[Data],  DfcUi[Data]  denote  signing  and  verification,  respectively,  of  data 
using  public  key  system. 

•  Fhash{Data)  is  a  one-way  has  function  of  Data. 

5.3.1    Secure  Distribution  of  Policy  Terms 

The  first  phase  in  secure  transit  control  is  the  PT  distribution  stage.  The 
security  mechanisms  to  assure  integrity  and  authenticity  of  PTs  are  disscussed.  The 
replay  prevention  and  the  confidentiality  of  PTs  are  discussed  after  that. 

Maintaining  integrity  and  authenticity  of  PTs 

In  order  to  provide  for  secure  distribution  of  Policy  Term  updates,  each  AD  must 
be  able  to  sign  its  own  PTs.  It  also  needs  to  know  how  to  authenticate  incoming  PTs. 
Because  of  the  Link  State  nature  of  the  protocol,  each  PT  update  must  be  flooded  to 
ADs  throughout  the  internetwork  so  that  all  participant  ADs  can  use  them  in  their 
PR  computation.  Before  using  a  new  PT,  each  AD  needs  to  verify  the  authenticity 
and  integrity  of  its  contents.  This  is  difficult  to  achieve  in  a  conventional  encryption 
environment,  as  the  number  of  potential  recipients  of  a  PT  update  can  be  quite  large. 
The  secure  version  of  PT  signed  by  ADi  is  shown  below  where  public  key  encryption 
and  the  certifying  authority  mechanisms  described  in  RFC1421  [82]  are  used  for  this 
particular  function. 
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SecurePT  =  [PT  \\  PTSIGi] 

PTSIGi  =  EKR.[FhashiPT)] 

Preventing  replay  of  PTs 

An  intruder  can  replay  previously  recorded  PTs  which  can  lead  to  incorrect  route 
calculations  in  recipient  domains.  There  are  two  basic  approaches  for  countering 
replay  attacks:  (i)  nonce  identifiers,  and  (ii)  timestamps.  Each  SecurePT  can  carry 
a  nonce  or  timestamp  supplied  by  the  source  entity. 

The  main  disadvantage  of  using  nonces  is  the  difficulty  in  their  verification.  In 
particular,  each  policy  gateway  (PG)  needs  to  keep  a  complete  history  of  past  nonces 
which  makes  the  verification  inefficient.  Timestamps  are  much  better  suited  for  this 
application.  First,  clocks  need  not  be  synchronized  continuously  between  the  source 
and  the  transit  PGs.  This  is  because  the  time  interval  of  any  two  successive  PT  up- 
date packets  are  relatively  large  compared  to  the  granularity  of  clock  synchronization. 
This  is  based  on  one  of  the  assumption  of  IDPR:  policies  and  inter-AD  connectivity 
change  relatively  slowly. 

Maintaining  confidentialitv  of  PTs 

Routing  information  distribution  is  one  area  of  policy  routing  where  confidential- 
ity measures  might  be  considered  useful.  However,  it  implies  that  the  entire  routing 
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update  must  be  encrypted  separately  for  each  anticipated  destination  AD.  In  gen- 
eral, this  is  impractical  regardless  of  the  type  of  encryption  used.  Since  a  link  state 
update  is  flooded  throughout  the  internetwork  (in  this  case,  to  all  ADs),  the  number 
of  potential  destinations  can  be  quite  large.  In  order  to  achieve  confidentiality  in 
this  environment,  the  source  of  a  link  state  update  needs  to  encrypt  the  update  T 
times  (where  T  is  the  total  number  of  ADs).  Furthermore,  the  traffic  due  to  update 
propagation  will  increase  T-fold. 

5.3.2    Route  Setup  Phase 

The  route  setup  phase  requires  that  each  intervening  AD  have  means  to  forward 
subsequent  data  packets  along  a  specific  Policy  Route.  As  described  in  IDPR  pro- 
posal, each  AD  along  the  route  must  be  supplied  with  the  next  hop  AD  at  PR  setup 
time.  The  purpose  of  PR  setup  is  to  establish  state  in  all  intervening  PGs  so  that 
Policy  Routing  decisions  can  be  made  in  advance  of  the  actual  communication,  and 
subsequent  data  packets  can  carry  a  minimum  of  PR-related  information,  thus,  re- 
ducing the  overhead  and  latency.  In  addition,  in  a  secure  PR  scheme,  each  AD  must 
be  able  to  authenticate  and  authorize  a  PR.  Authentication  means  verifying  that  a 
PR  was  issued  by  a  recognized  entity,  and  was  not  tampered  with.  Authorization 
entails  making  sure  that  a  PR  conforms  to  a  local  policy. 

This  PR  authentication  provides  protection  from  possible  security  attacks.  First, 
it  protects  from  fabrication  or  modification  attacks  on  PRs.  In  order  to  achieve  this, 
each  PR  must  be  traceable  to  the  issuing  AD.  In  other  words,  it  must  be  signed 
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with  an  unforgeable  signature.  For  all  intervening  ADs,  this  would  provide  for  non- 
repudiation  of  issuance  and  sender  authenticity. 

It  also  protects  from  replay  of  previously  issued  PR  setup  packets.  This  can 
be  prevented  if  a  timestamp  is  included  within  each  PR  setup.  The  signature  of  a 
PR  setup  packet  becomes  dependent  on  this  timestamp,  and,  makes  replay  detection 
possible  within  the  granularity  of  the  timestamp  and  clock  synchronization.  As  the 
number  of  setups  is  relatively  small  compared  to  the  number  of  data  packets,  rela- 
tively coarse  timestamp  granularity  (e.g.,  1  ms)  should  be  adequate  and  is  preferable 
to  the  management  required  to  keep  track  of  unique  sequence  numbers  also  referred 
to  as  nonces. 

Secure  PR  setup 

As  with  PT  update  distribution,  we  are  concerned  with  data  integrity  and  au- 
thenticity of  setup  packets.  However,  unlike  PT  updates,  PRs  are  set  up  frequently, 
and  increased  latency  is  experienced  directly  by  end  users.  Thus,  we  are  far  more 
concerned  with  the  per-signature  overhead  for  setup  than  we  are  for  PT  distribu- 
tion. Consequently,  the  use  of  both  conventional  and  public  key  encryption  signature 
mechanisms  will  be  investigated. 

As  discussed  earlier,  conventional  encryption  implies  a  significant  key  manage- 
ment burden,  since  an  AD  has  to  share  a  secret  key  with  every  other  AD  that  it  ever 
communicates  with.  Moreover,  it  entails  computing  a  PR  signature  for  every  AD 
involved,  whereas  a  single  PR  signature  verifiable  by  all  intervening  ADs  is  sufficient 
in  public  key  encryption.  A  signed  PR  setup  packet  is  calculated  as  such: 
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SecurePRSETUP  =  [PRSETUP  \\  PRSIGsrc] 

PRSIGsrc  =  EKR,jFhash{PRSETUP)] 

where  Ekr,,.c[I]  denotes  the  signing  of  /  with  private  key  of  ADarc-  Given  a 
strong  one-way  hash  function  (such  as  MD5)  and  a  strong  encryption  function  (such 
as  RSA),  this  signature  is  sufficient  to  maintain  the  integrity  of  the  PR  setup  packet. 
Timeliness  can  be  maintained  by  timestamping  the  setup  packet. 

On  the  other  hand,  a  typical  PR  traverses  a  relatively  small  number  of  ADs 
(N  is  much  less  than  the  diameter  of  the  internetwork).  This  makes  conventional 
encryption  a  viable  choice  since  a  PR  would  only  have  to  be  signed  N  times.  A 
signed  PR  setup  packet,  in  this  Ccise,  is  shown  as: 

PRSIGi  =  EK,,JFHash{PRSETUP)] 

Providing  data  packet  integrity 

If  data  packet  integrity  is  desired,  the  issuing  ADsrc  needs  to  generate  a  new 
data  signature  key,  Ksig,  for  use  in  whatever  per-packet  data  integrity  variation  is 
used.  Kgig  must  be  communicated  in  secret  to  each  ADi.  This  requires  that  ADsrc 
encrypt  K^ig  N  times,  that  is,  compute  EKuAKsig]  for  all  ADi. 
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When  the  PR  setup  packet  propagates  along  the  route  each  ADi  obtains  Ksig 
by  decrypting  it  with  ADi^s  private  key.  Then  each  ADi  recomputes  and  verifies 
PRSIGsrc,  and  validates  the  timestamp  (possible,  by  comparing  it  to  the  timestamp 
of  the  previous  setup  packet,  which  it  may  choose  to  keep).  It  then  proceeds  to 
authorize  the  PR. 

At  this  point,  each  ADi  is  assured  that: 

•  the  PR  is  valid,  in  other  words,  does  not  violate  local  policy, 

•  the  PR  is  authentic,  that  is,  issued  by  a  recognized  entity,  and 

•  the  PR  is  fresh,  that  is,  issued  recently. 

5.3.3    Packet  Forwarding  Phase 

After  a  PR  has  been  set  up,  subsequent  data  packets  can  take  advantage  of 
the  PR  state  in  intermediate  ADs.  First,  instead  of  a  full  PR,  each  data  packet 
carries  only  an  abbreviated  version  referred  to  as  the  PR  header.  Second,  the  state 
in  all  intervening  PGs  allows  them  to  bypass  expensive  authorization  checks  on  a 
per  packet  basis.  A  PR  header  only  needs  to  contain  the  information  necessary  to 
identify  the  appropriate  state  in  intervening  PGs.  Its  exact  contents  are  described  in 
the  next  section. 

Maintaining  integrity  and  authenticitv  of  data  packet 

Assuming  appropriate  security  measures  to  prevent  PR  setup  threats  above, 
there  remains  the  possibility  of  malicious  attack  at  packet  forwarding  time:  an  in- 
truder located  at  some  point  along  a  PR  can  copy  a  valid  PR  header  from  a  legitimate 


109 


packet,  attach  its  own  data  and  send  it  along  a  PR,  thus,  obtaining  service  fraudu- 
lently. This  attack  can  be  remedied  if  each  data  packet  is  signed  by  the  source. 

SecureDATA  =  [PRHEADER  \\  DATA  \\  DATASIG] 

PRHEADER  =  [AD,rc  \\  PG„c  \\  TSsrc] 
DATASIG  =  EK,„[Fhash{PRHEADER  ||  Packet)] 

Depending  on  the  type  of  encryption  used,  the  overhead  incurred  by  signing 
each  data  packet  (or  even  a  hash  function  thereof)  can  be  prohibitively  high.  Per- 
packet  overhead  includes  the  signature  computation  at  the  source  and  its  subsequent 
verification  at  each  PG  hop  en  route  to  the  destination. 

If  only  sender  authenticity  and  data  integrity  is  desired,  then  the  tradeoff  be- 
tween conventional  and  public  key  signature  of  the  hash  function  is  dependent  upon 
their  relative  speeds.  In  order  to  minimize  per  packet  processing  overhead,  we  will 
assume  the  use  of  conventional  encryption  for  data  packet  signature  computation. 
In  this  case,  a  secret  key  Kgig  is  distributed  during  setup  for  use  in  data  integrity 
verification.  This  key  is  shared  by  all  ADs  on  the  route.  As  a  result,  a  simple  group 
channel  is  established.  However,  it  is  possible  for  any  AD  along  the  route  to  mas- 
querade as  the  source  AD  for  the  duration  of  that  PR.  Moreover,  the  secret  key  must 
be  distributed  without  disclosure.  This  requires  the  public  key  scheme  to  encrypt  the 
key  multiple  times  separately  with  the  public  key  of  each  AD  in  the  PR. 
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Prevention  of  data  packet  replay 

An  intruder  can  replay  previously  recorded  data  packets  which  can  lead  to  un- 
justified charging  and/or  denial  of  service.  We  only  need  to  protect  against  replayed 
packets  within  the  hfe-span  of  the  associated  PR.  After  a  PR  expires  or  is  closed,  all 
packets  carrying  the  expired  PR  identifier  will  not  be  processed. 

There  are  two  basic  approaches  for  countering  replay  attacks:  (i)  nonce  iden- 
tifiers, and  (ii)  timestamps.  The  main  disadvantage  of  using  nonces  is  the  difficulty 
in  their  verification.  In  particular,  each  relevant  entity  (each  PG,  in  our  case)  needs 
to  keep  a  complete  history  of  past  nonces  which  makes  the  verification  inefficient. 
Timestamps  are  much  better  suited  for  this  application.  First,  clocks  need  not  be 
synchronized  continuously  between  the  source  and  the  transit  PGs.  This  is  because 
a  PR  setup  packet  is  timestamped;  its  timestamp  can  be  used  as  a  lower-bound  for 
subsequent  data  packets  in  all  intervening  PGs.  Furthermore,  if  the  intervening  PGs 
maintain  a  more  current  lower-bound  timestamp  {t lower),  opportunities  for  replay  can 
be  reduced  further. 

Consider  the  following  simple  protocol: 

1.  When  a  PR  is  issued,  PGarc  timestamps  the  PR  setup  packet,  and  distributes 
the  timestamp,  tsetup,  in  a  secure  fashion  to  all  intervening  PGs  in  transit  ADs. 
All  transit  PGs  initiahze  their  tiower  values  for  this  PR  to  tsetup- 

2.  When  a  data  packet  is  sent,  the  originating  PG  timestamps  its  PR  header  with 

tdata- 
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3.  When  this  data  packet  reaches  a  transit  PG,  its  PR  header  is  examined  and 
the  tdata  is  compared  to  t lower-  Three  outcomes  are  possible: 

(a)  tdata  <  tiower-  the  difference  between  the  two  values  is  examined.  If  it  is 
less  than  some  (locally  defined)  threshold,  St,  the  packet  can  be  forwarded. 
Otherwise,  the  packet  is  discarded. 

(b)  tdata  >  tiower-  the  packet  is  forwarded  and  tiower  is  set  to  tdata-  Of  course, 
a  PG  may  get  suspicious  if  the  difference  is  too  large. 

(c)  tdata  —  tiower'-  this  Can  occur  when  two  successive  data  packets  belonging 
to  the  same  PR  stream  carry  the  same  timestamp.  To  distinguish  between 
such  packets,  it  would  be  necessary  to  keep  additional  information  such 
as  a  packet  signature,  for  the  last  data  packet  processed.  However,  it  is 
desirable  for  the  clock  rate  to  be  at  least  as  fast  as  the  maximum  packet 
rate.  This  would  preclude  duplicate  timestamps  on  data  packets. 

This  protocol  prevents  most,  but  not  all,  replay  attacks.  In  order  to  prevent  all 
replay  attacks,  6t  values  must  be  set  to  zero  in  all  transit  PGs,  which  would  essentially 
disallow  any  out-of-order  data  packets.  This  is  a  choice  that  will  not  be  practical  for 
environments  where  out-of-order  packets  are  a  frequent  occurrence. 

5.4    Cost  of  Securitv  Mechanisms 

Our  purpose  in  this  section  is  to  investigate  bounds  on  achievable  data  rates 
with  the  security  schemes  described  above.  We  can  identify  four  important  overhead 
contributors  listed  in  the  order  of  magnitude: 
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•  Per  Packet  Signature  Overhead 

•  Increased  Packet  Length 

•  Setup  Overhead  * 

•  Other  Additional  Per  Packet  Processing 

In  the  remainder  of  this  section  we  analyze  each  of  the  above  contributing  factors 
in  several  variations  of  the  general  scheme. 

5.4.1    Per  Packet  Signature  Overhead 

Per  packet  signature  costs  are  largely  dependent  upon  the  particular  variation 
of  data  integrity  checking.  Latency  is  a  much  more  critical  concern  with  respect  to 
forwarding  of  data  packets  than  in  the  case  of  PR  setup.  For  this  reason,  many 
ADs  are  likely  to  forego  per-packet  signature  and  verification  of  most  traffic.  N  hash 
calculations  and  encryptions  are  needed  per  packet  if  all  the  transit  ADs  verify  the 
packet  integrity.  There  are  other  possibilities  whereby  ADs  can  trade  the  level  of 
protection  for  the  amount  of  overhead  incurred.  A  spectrum  of  modes  of  packet 
verification  and  corresponding  costs  are  given  below: 

•  Full  Transit  Verification:  In  network  environments  where  data  integrity  and 
security  concerns  outweigh  the  overhead  of  extra  processing,  the  data  portion 
of  every  packet  is  subject  to  forgery  and  must  be  checked  (for  authenticity  and 
integrity)  at  each  hop  on  its  way  to  the  destination.  Every  data  packet  is  signed 
at  the  source  and  checked  at  each  AD  hop  en  route.  A'^  +  1  hash  calculations 
and  A''  +  1  encryptions  are  needed  per  packet. 
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•  No  Transit  Verification:  If  authenticating  data  in  each  packet  at  every  hop 
is  prohibitively  expensive,  end-to-end  data  integrity  similar  to  that  in  stub 
access  control  schemes  may  be  appropriate.  Every  data  packet  is  signed  at  the 
source  but  is  checked  only  at  the  destination.  This  approach  has  limitations, 
most  notably  the  fact  that  the  modification  attack  will  not  be  detected  until 
the  packet  reaches  the  destination  AD.  This  can  result  in  unauthorized  use  of 
transit  resources  and,  inappropriate  billing  of  the  source.  On  the  other  hand, 
this  approach  benefits  from  lower  per  packet  latency  (2  hash  calculations  and 
2  encryptions)  which  is  independent  of  the  PR's  length. 

•  Selective  Transit  Verification:  If  No  Transit  Verification  exposes  transit 
resources  to  excessive  misuse,  yet  Full  Transit  is  too  expensive,  some  selected 
ADs  can  perform  data  integrity  checks.  Every  data  packet  is  still  signed  at 
the  source,  but  only  selected  transits  and  the  destination  check  the  signature. 
The  source  AD  can  designate  at  PR  setup  time  some  specific  transit  ADs  to 
perform  data  integrity  checks,  k  +  2  hash  calculations  and  k  +  2  encryptions 
are  needed  when  k  transit  ADs  are  designated. 

•  Selective  Packet  Verification:  Instead  of  each  transit  AD  having  to  authen- 
ticate each  packet,  it  may  suffice  to  authenticate  every  m-th  packet.^  In  the 
simplest  version  of  this  patterned  authentication  scheme,  ADsrc  would  choose 
m  at  random  from  a  locally  defined  range  of  values  and  then  specify  m  during 

^Alternatively,  transit  ADs  can  choose  their  own  values  or  probabilities  to  verify  transit  packets 
selectively.  In  this  case,  all  data  packets  are  signed  at  the  source. 
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route  setup.  In  this  scheme  only  1/m  data  packets  are  signed  at  the  source  and 
the  same  1/m  packets  are  checked,  and  therefore,  {N  +  l)/m  hash  calculations 
and  (N  +  l)/m  encryptions  are  required.  In  return  for  reduced  overhead,  if 
the  value  for  m  is  discovered  by  an  intruder  then  (m  —  l)/m  of  the  PR's  band- 
width can  he  abused.  Moreover,  this  method  implies  that  care  must  be  taken 
to  recover  from  lost  and  out-of-order  packets. 

5.4.2  Packet  Length  Overhead 

Increased  packet  length  is  incurred  by  the  PR  header  carried  in  every  data 
packet.  It  is  anticipated  that  the  length  of  this  header  will  be  on  the  order  of  32 
bytes.  When  the  replay  prevention  is  used  independent  of  the  data  authentication, 
the  cost  amounts  to  one  additional  PR  header  field  (32  to  64  bits  depending  on  the 
timestamp  granularity). 

5.4.3  Setup  Overhead 

PR  setup  is  accomplished  by  composing  and  sending  a  packet  containing  the 
entire  PR  as  described  above.  The  costs  include: 

•  N  conventional  encryption  operations  by  ADsrc  to  encrypt  K^ig  for  each  inter- 
vening ADi,  if  data  integrity  is  checked  en  route. 

•  A  hash  function  computation  over  the  entire  PR  setup  packet  followed  by  a 
single  pubhc  key  signature  computation  of  the  128-bit  hash  value. 

•  N  hash  function  computations  and  N  public  key  signature  verifications  for 
verifying  the  setup  packet  signature  en  route. 
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•  A'^  conventional  decryption  operations  by  each  ADi  to  decrypt  Kaig.  However, 
this  can  be  done  after  the  setup  packet  is  forwarded  to  the  next  hop  and  so 
does  not  contribute  directly  to  the  setup  latency. 

5.4.4    Other  Per  Packet  Processing  Costs 

Additional  (other  than  encryption)  processing  costs  are  incurred  mainly  by  the 
added  logic  in  routers  for  processing  of  PR-based  packets,  in  particular,  table  lookups. 
Generally,  the  time  spent  on  lookups  is  far  overshadowed  by  the  encryption  costs. 


CHAPTER  6 
CONCLUSIONS  AND  FUTURE  WORK 

Security  has  become  one  of  the  most  important  research  topics  in  internetwork 
environment,  and  more  in-depth  exploration  and  investigation  into  different  aspects  of 
computer  and  internetwork  security  are  needed.  In  this  dissertation  work,  significant 
research  results  have  been  shown  by  either  enhancing  the  performance  (efficiency)  or 
increasing  the  power  (effectiveness)  of  the  access  control  and  authentication  services 
and  mechanisms.  Conclusions  of  these  works  and  possible  future  tasks  are  discussed 
individually  on  each  research  area. 

6.1    Internetwork  Access  Control 

First,  a  design  and  analysis  of  a  secure  and  efficient  internetwork  access  control 
scheme  entitled  PASS  is  presented.  PASS  enforces  access  control  policy  on  packet 
(i.e.,  network  layer)  level.  This  packet-level  approach  is  more  efficient  and  flexible 
than  a  high-level  gateway  approach  since  the  high-level  control  suffers  from  high-level 
processing  overhead  and  requires  a  separate  gateway  function  for  each  application  it 
supports.  PASS  is  designed  for  the  environment  where  simple  source/destination 
filter  and  access  control  list  are  not  sufficient  to  enforce  policies  due  to  the  dynamic 
nature  of  the  internetwork  and  insufficient  logical  information  in  the  addresses  used. 
PASS  incurs  less  communication  overhead  than  existing  packet-level  access  control 
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schemes  and  reduces  security  vulnerabilities  in  the  interdomain  authentication  and 
key  distribution  stage  by  using  public  key  certificates. 

Recently,  many  suggestions  and  proposals  have  come  out  to  make  internetwork 
transactions  secure.  Some  of  those  efforts  suggest  modifications  of  some  part  of  ex- 
isting protocols  and  standards,  and  others  demand  rather  fundamental  changes  to 
achieve  the  same  goal.  The  former  approaches  introduce  the  possibility  of  inconsis- 
tency problems  while  the  latter  approaches  quite  often  impose  a  financial  and  tech- 
nical burden.  PASS  is  one  of  the  former  approaches  which  does  not  require  drastic 
changes  in  the  system  environment.  PASS  does  not  impact  intra-AD  communication 
and  has  no  influence  on  the  end-systems  that  do  not  partake  in  inter- AD  commu- 
nication. However,  it  also  can  be  used  as  a  part  of  more  complete  security  service, 
performing  low-level  authorization  and  authentication  while  higher-level  mechanisms 
provide  required  logical  information  to  be  used  to  make  those  decisions.  One  of  the 
possible  ways  is  discussed  in  the  appendix  which  is  about  the  integration  of  PASS 
with  a  firewall. 

6.2    Interdomain  Authentication 

To  make  an  internetwork  transactions  secure,  it  is  crucial  to  have  a  reliable  au- 
thentication protocol  between  principals  in  different  domains.  A  secure  and  efficient 
public-key  based  interdomain  authentication  protocol  has  been  proposed  which  is 
used  in  PASS  scheme.  This  new  protocol  makes  use  of  an  international  standard 
directory  authentication  service  (ITU-T  X.509)  as  a  public  key  provider.  This  re- 
moves an  unrealistic  assumption  about  the  availability  of  a  trusted  third  party  used 
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in  most  other  existing  protocols.  The  authentication  goals  of  the  protocol  are  verified 
by  using  BAN  logic.  Many  known  security  flaws  in  existing  standards  and  protocols 
have  been  addressed  in  this  new  protocol.  One  of  these  is  shown  in  an  example  of  a 
replay  prevention.  Two  variations  of  this  protocol  are  given  for  the  situations  which 
require  one-way  authentication  and  one-way  pass. 

More  and  more  security  mechanisms  use  public  key  technology  because  of  many 
advantages  it  gives.  One  of  the  most  significant  advantages  is  that  it  does  not  re- 
quire on-line  trusted  key  distribution  centers.  In  addition  to  that,  it  scales  well  to  a 
very  large  internetworks  due  to  its  linear  complexity  of  key  management  overhead. 
Therefore,  the  proposed  interdomain  authentication  protocol  fits  well  in  emerging 
internetworks  which  quite  often  composed  of  large  number  of  ADs. 

Before  the  ubiquitous  availability  of  the  standard  directory  service,  some  spe- 
cialized sever  applications  can  be  implemented  to  be  used  with  the  proposed  authen- 
tication protocol.  One  of  such  servers  is  the  Certification  Distribution  Center  that 
is  used  to  distribute  public  key  certificates  and  other  authentication-related  informa- 
tion to  the  communicating  principals.  The  issues  of  how  to  generate,  maintain,  and 
distribute  this  information  could  be  worthwhile  to  explore. 

6.3    Secure  Control  of  Transit  Internetwork  Traffic 

To  complement  the  internetwork  policy  enforcement  scheme,  a  secure  transit 
traffic  control  mechanism  is  proposed.  First,  some  stub-network  access  control  tech- 
niques are  investigated  for  possible  extensions  of  them  to  transit  control  mechanisms. 
From  this,  it  is  found  out  that  controlling  access  to  network  resources  in  intermediate 
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domains  is  closely  related  to  packet  routing.  Next,  two  interdomain  routing  protocols 
are  investigated,  which  make  routing  decisions  based  on  policy  attributes  in  addition 
to  the  conventional  link  metrics.  Security  mechanisms  are  added  to  the  Inter-Domain 
Policy  Routing  protocol  (IDPR)  to  make  it  a  secure  transit  control  scheme.  The  cost 
of  the  added  security  mechanisms  is  analyzed  for  several  modes  of  transit  packet 
verification. 

This  work  proposed  security  mechanisms  that  utilize  policy  routing  to  prevent 
unauthorized  use  of  network  resources,  and  control  routing  of  packet  data  across  AD 
boundaries.  The  proposed  mechanisms  were  designed  to  support  inter-operability 
across  ADs  with  heterogeneous  policies  to  the  extent  that  their  combined  policies 
allow.  Moreover,  these  preventative  transit  control  mechanisms  can  inter-operate 
with  detection-based  (that  is,  non-secure)  PR  mechanisms. 

A  stub  network  access  control  (such  as  PASS)  is  concerned  with  policy  enforce- 
ment with  respect  to  non-transit  internetwork  traffic.  In  other  words,  the  issue  is  how 
an  AD  can  control  both  inbound  and  outbound  traffic  at  its  network  boundaries.  On 
the  other  hand,  a  transit  network  access  control  is  concerned  with  policy  enforcement 
with  respect  to  transit  internetwork  traffic.  Controlling  access  to  transit  network  re- 
sources (such  as  routers  and  links)  requires  additional  protocol  support  because  of 
the  need  to  coordinate  routing  decisions  among  all  intervening  networks.  These  two 
access  controls  should  work  in  harmony  to  achieve  a  dependable  policy  enforcement 
in  internetwork  environment.  The  integration  of  these  two  access  controls  could  be 
a  challenging  work  since  they  have  different  requirements  and  natures. 


APPENDIX  A 
INTEGRATION  OF  PASS  WITH  GTGB 

In  this  appendix,  we  discuss  the  possibilities  and  related  issues  in  combining 
PASS  and  Gemini  Trusted  Guard  Base  (GTGB)  which  is  being  setup  in  our  Com- 
puter Network  Laboratory.  The  GTGB  prototype  runs  on  the  Gemini  Trusted  Net- 
work Processor  (GTNP)  and  acts  as  a  firewall  between  a  set  of  one  or  more  Local 
Area  Networks  (LANs)  and  a  Wide  Area  Network  (WAN).  The  GTGB  prototype  per- 
forms trusted  separation  of  data  at  different  levels  and  packet  filtering.  The  GTGB 
prototype  can  be  configured  to  keep  an  audit  trail  of  violations  detected  during  op- 
eration. The  internetwork  may  consist  of  Gemini  GTGB  prototype  systems,  routers, 
and  various  workstations  at  different  security  levels.  The  GTGB  prototype  enforces 
an  overall  network  mandatory  security  policy  with  the  use  of  cryptographic  seals  ap- 
plied to  all  TCP/IP  packets  passing  through  the  WAN.  This  cryptoseal  is  generated 
using  the  Data  Encryption  Standard  (DES)  algorithm.  A  unique  key  may  be  used 
for  each  IP  address  pair.  The  cryptoseal  is  a  function  of  this  key,  the  TCP/IP  packet, 
and  the  security  level  of  the  LAN  port [83]. 

A.l    GTGB  Functionality 

Each  Guard  acts  as  a  security  firewall  between  untrusted  single-level  LANs 
operating  at  different  security  levels.  The  LANs  connected  to  the  Guards  are  not 
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considered  trusted  networks  because  information  is  allowed  to  flow  freely  between 
various  LANs  via  a  router. 

The  GTGB  accepts  and  transmits  information  at  the  IP  level.  It  examines 
the  IP  datagram  header  fields  as  well  as  the  TCP  packet  header  fields  encompassed 
within.  The  GTGB  does  not  perform  fragmentation  of  datagrams,  nor  does  it  accept 
packets  that  have  been  fragmented  between  GTGB  systems  (i.e.,  within  the  WAN). 

The  Guards  are  intended  to  provide  six  security  protection  mechanisms: 

•  IP  Source/Destination  Address  Pair  Verification:  Datagrams  are  only 
transferred  through  the  Guard  if  they  contain  a  source/destination  IP  address 
pair  which  has  been  configured  off-line  to  be  valid.  The  datagram  is  discarded 
and  an  audit  record  is  generated  when  a  datagram  enters  with  an  invalid  IP 
address  pair. 

•  Incoming  Physical  LAN  Port  Verification:  The  Guard  ensures  that  each 
datagram  it  received  came  in  from  the  expected  physical  port.  The  datagram 
is  discarded  and  an  audit  record  is  generated  when  a  datagram  enters  from  an 
invalid  physical  port. 

•  TCP/UDP  Destination  Port  Filtering:  The  Guard  provides  TCP/IP 
packet  filtering  based  on  the  network  services  (i.e.,  TCP/UDP  port  number) 
allowed  per  physical  destination  port.  The  datagram  is  discarded  and  an  audit 
record  is  generated  when  the  packet  contains  a  TCP/UDP  destination  port 
number  below  1024  that  is  not  allowed  for  a  particular  LAN  port.  The  current 
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design  of  the  Guard  allows  all  TCP/UDP  destination  port  numbers  at  or  above 
1024  to  pa^s  through  because  these  ports  are  generally  used  by  reply  packets. 

Detection  of  Unsolicited  Public  Access:  The  Guard  detects  and  discards 
datagrams  which  originated  from  a  public  network  that  have  a  TCP/UDP 
destination  port  number  below  1024. 

Detection  of  Data  Modifications:  For  Private-to-Private  connections,  the 
Guard  detects  modifications  of  the  content  of  each  datagram  that  travels  across 
the  WAN  by  using  the  cryptographic  sealing  technique.  The  Guard  generates 
a  cryptoseal  for  each  datagram  to  be  sent  out  to  the  WAN,  and  checks  the 
cryptoseal  when  receiving  a  datagram  from  the  WAN.  There  is  a  separate  cryp- 
tographic key  used  to  generate  cryptoseals  for  each  valid  IP  address  pair  in  the 
network.  The  datagram  is  discarded  and  an  audit  record  is  generated  when  a 
modification  of  the  packet  within  the  WAN  is  detected. 

Controlled  Data  Distribution:  For  Private-to-Private  connections,  the  Guard 
ensures  that  the  security  level  of  the  data  is  equal  to  the  security  level  of  the 
destination  port.  This  is  accomplished  via  the  cryptoseal  because  the  cryp- 
toseal is  a  function  of  the  port's  security  level.  The  datagram  is  discarded  and 
an  audit  record  is  generated  when  a  datagram  is  sent  to  a  LAN  operating  at  a 
security  level  that  is  different  than  the  security  level  of  the  LAN  from  which  it 
originated. 
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For  Private-to-Public  connections,  the  Guard  releases  the  data  based  on  the 
information  that  is  configured  off-line  by  Mandatory  Security  Administrator 
(MSA),  information  that  is  configured  off-line.  A  datagram  (without  a  cryp- 
toseal)  destined  to  a  LAN  port  that  is  not  allowed  to  have  public  connections 
is  discarded  and  an  audit  record  is  generated. 

•  Audit:  The  Guard  maintains  and  protects  a  log  of  auditable  events.  There  are 
six  security-relevant  auditable  events:  invalid  IP  address  pair,  invalid  source 
physical  port,  unsolicited  pubhc  access  denied,  invaUd  TCP/UDP  port  permis- 
sion, invalid  cryptographic  seal,  and  illegal  public  network  access.  There  are 
two  informative  auditable  events  for  Private-to-Public  connections:  outgoing 
(LAN-to-WAN)  public  network  access,  and  incoming  (WAN-to-LAN)  public 
network  access.  Each  audit  record  is  transmitted  to  a  printer,  to  the  GTGB 
operator  console,  and  optionally  to  the  hard  disk. 

A.2    Configuration  of  Gemini-UF  GTGB  Testbed 

All  GTGB  systems  will  have  one  WAN/MAN  port  and  several  LAN  ports.  All 
TCP/IP  packets  first  travel  into  one  of  the  GTGB  system's  LAN  ports  and  out 
the  WAN  port.  These  packets  then  get  routed  by  an  external  router  back  into  the 
same  GTGB's  WAN  port  (or  into  another  GTGB  WAN  port  on  the  WAN)  and  out 
one  of  the  LAN  ports.  In  other  words,  all  packets  must  travel  from  the  source  LAN 
through  a  GTGB  system  to  the  WAN,  and  then  back  through  a  GTGB  system  to  the 
destination  LAN.  Only  one  network  device  (i.e.,  a  router/bridge)  can  communicate 
with  the  Guard  per  port. 
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Figure  A.l.  The  network  configuration  of  Gemini-UF  Testbed 

The  GTGB  system  provides  protection  at  the  IP  layer  of  the  TCP/IP  protocol 
suite.  Therefore,  any  application  developed  for  the  TCP/IP  protocol  suite  can  be 
used  with  the  GTGB. 

A. 2.1    Private- To-Private  Secure  Connections 

The  network  configuration  shown  in  Figure  A.l  illustrates  how  a  pair  of  GTGB 
systems  may  be  used  to  create  a  virtual  private-to-private  secure  connection  with 
trusted  separation  of  data  at  different  security  levels  over  a  public  network. 

This  testbed  consists  of  seven  LANs  operating  at  two  security  levels  ( "secu- 
rity JeveLO"  and  "security JeveLl").  Gemini  LANs  0  and  1  and  UF  LANs  0  and  1 
are  operating  with  a  level  of  "security JeveLO",  while  Gemini  LAN  2  and  UF  LANs 
2  and  3  are  operating  with  a  level  of  "securityJeveU". 
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The  intent  of  the  GTGB  system  is  to  ensure  that  the  data  of  a  LAN  of  a 
particular  security  level  is  only  accessible  to  other  LANs  of  the  same  security  level. 
For  example,  in  Figure  A.l,  information  may  flow  between  Gemini's  205.179.16.68 
and  ds9  in  UF  side,  but  no  information  is  allowed  to  flow  between  enterprise  and  ds9 
at  UF.  This  shows  how  one  Guard  system  can  ensure  trusted  separation  of  data  at 
different  security  levels  when  all  the  LANs  are  located  within  an  organization. 

The  Private- To-Private  connections  are  considered  as  secure  connections  because 
any  information  passing  between  the  LANs  across  the  WAN/MAN  is  mediated  by 
the  Guards  according  to  the  policies  set  by  the  designers  of  the  network. 

A. 2. 2    Private- To-Public  Connections 

This  figure  also  illustrates  how  one  Guard  system  may  be  used  to  provide  con- 
trolled access  to  network  services  over  a  public  network,  including  Internet. 

Under  MSA  control,  one  of  the  workstations  in  Gemini  LAN  0  (e.g.  205.179.16.136) 
can  be  enabled  to  have  access  to  the  Internet.  The  workstation  205.179.16.136  can 
also  communicate  with  other  workstations  in  Gemini  LAN  1  if  so  allowed  by  the 
system  policy  and  configured  by  the  MSA.  The  decision  to  allow  a  workstation  that 
is  exposed  to  public  network  access  to  exchange  data  with  other  workstations  in  the 
private  network  should  only  be  made  after  careful  risk  and  vulnerability  assessment 
is  done.  With  regard  to  Gemini  LANs  0  and  1,  it  should  be  recognized  that  the 
current  design  of  the  GTGB  cannot  prevent  certain  forms  of  Internet  attacks  which 
may  be  possible  on  such  exposed  networks.  It  is  strongly  recommended  that  a  LAN 
configured  to  allow  access  to  the  Internet  operates  at  a  dedicated  security  level. 
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The  Private-to-Public  connections  are  also  considered  as  secure  connections  be- 
cause they  are  controlled  by  the  MSA  based  on  the  system  policy.  Information 
flow  between  selected  workstations  and  the  public  network  is  still  subjected  to  both 
Mandatory  Access  Control  (MAC)  and  Discretionary  Access  Control  (DAC)  enforced 
by  the  Guard.  For  this  type  of  connection,  there  is  no  cryptographic  checksum  in 
the  IP  datagram.  Hence,  the  integrity  check  on  the  datagram  will  not  be  performed, 
and  the  Guard  will  make  the  decision  whether  to  release  the  data  or  not  based  on 
MSA-specified  information  rather  than  on  the  cryptographic  checksum. 

A.3    Integration  of  PASS  into  GTGB  Testbed 

There  may  be  several  different  ways  of  integrating  PASS  scheme  with  GTGB 
system  depending  on  the  degree  of  interaction  between  those  two.  These  ways  are 
grouped  in  two  different  situations  and  discussed  below. 

A.3.1    Coexistence  of  PASS  and  GTGB 

In  this  mode  of  integration,  PASS  and  GTGB  just  coexist  without  any  inter- 
action between  them.  In  other  words,  GTGB  verifies  the  packets  by  looking  up  the 
verification  table  and  generates/ verifies  cryptoseal  regardless  of  the  type  of  packets 
(e.g.,  PASS  or  non-PASS  packets).  On  the  other  hand,  PASS  scheme  performs  ex- 
actly the  same  functionalities  as  described  in  Chapter  3  without  being  hindered  by 
the  existence  of  GTGB.  This  is  possible  since  GTGB  is  designed  to  be  transparent 
to  the  local  hosts  and  the  pass  information  in  PASS  packet  is  not  supposed  to  be 
checked  by  GTGB.  In  other  words,  PASS  end-system  talks  with  its  local  lACG  with- 
out knowing  the  existence  of  GTGB  between  them  and  on  the  other  hand,  GTGB  just 
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verifies  the  packets  IP  addresses  and  port  numbers  without  concerning  the  contents 
of  IP  option  field  except  the  cryptoseal. 

The  exit  authorization  phase  of  the  PASS  protocol  works  as  follows: 

1.  An  end-system  mockingbird  at  UF  LAN  2  in  Figure  A.l  sends  a  packet  to 
205.179.16.68  in  Gemini. 

2.  GTGB  captures  this  packet  and  verifies  that  the  packet's  source  and  destination 
IP  address  pair  matches  an  entry  in  Address  Verification  Table  (AVT)  and 
verifies  that  the  port  number  from  which  the  packet  was  received  matches  the 
port  number  specified  in  the  above  entry. 

i)  If  the  above  checks  are  successful  and  the  IP  address  pair  is  configured  for 
Private-to-Private  connection,  a  cryptoseal  of  the  packet  data  is  generated 
using  the  key  from  the  above  entry  and  stored  within  the  IP  header.  No 
cryptoseal  will  be  appended  to  the  IP  header  if  the  address  pair  is  con- 
figured for  Private-to-Public  connection.  The  packet  is  sent  out  to  the 
lACG. 

ii)  If  the  checks  are  not  successful  (indicating  an  invalid  packet),  the  packet 
will  be  discarded. 

3.  The  local  lACG  (voyager,  in  this  example)  finds  out  that  the  packet  does  not 
have  proper  pass  and  reply  with  a  REJECT  packet  which  notifies  mockingbird 
that  the  intended  destination  is  non-local,  and  that  it  must  acquire  a  pass  by 
first  getting  authorization  and  authentication  from  a  local  lACG. 
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4.  GTGB  does  the  similar  check  on  the  REJECT  packet  and  forwards  it  to  mock- 
ingbird if  the  check  is  successful. 

5.  mockingbird  sends  an  AUTH-REQUEST  packet  to  voyager. 

6.  GTGB  does  the  similar  check  on  this  packet  and  forwards  it  to  mockingbird 
if  the  check  is  successful. 

7.  voyager  performs  authorization  and  authentication  with  mockingbird  on  re- 
ceiving the  AUTH-REQUEST  packet.  GTGB  does  the  similar  checks  on  all  the 
packets  exchanged  between  voyager  and  mockingbird  during  this  process. 

From  this  description,  we  notice  a  possible  problem  and  a  redundancy.  That 
is,  some  higher- level  mechanism  might  be  needed  to  resend  the  packets  discarded  at 
GTGB  without  notifying  the  sender  of  the  fact.  As  to  the  redundancy,  we  notice 
that  there  could  be  a  quite  amount  of  overlap  between  the  AVT  check  of  GTGB  and 
authorization  of  lACG.  The  authorization  procedure  may  be  replaced  by  the  AVT 
check  of  GTGB  if  the  authorization  is  solely  based  on  the  access  control  list  type  of 
information.  We  will  discuss  further  in  next  section. 

A.3.2    Interactions  between  PASS  and  GTGB 

In  this  section,  we  probe  some  possibilities  of  interactions  between  PASS  and 
GTGB  by  replacing  or  relocating  some  of  components  of  PASS  scheme  to  GTGB. 


GTGB  as  an  Authorization  Server 

As  indicated  above,  it  could  reduce  overhead  that  the  AVT  check  of  GTGB  is 
used  as  an  authorization  service  of  PASS  protocol  at  lACG.  The  Address  Verification 
Table  holds  the  following  information: 

•  Valid  IP  source/destination  address  pairs  with  their  respective  IP  address  mcisks. 

•  Physical  LAN  port  associated  with  the  originating  LAN  for  each  address  pair. 

•  Cryptographic  sealing  key  for  each  address  pair. 

•  An  indicator  specifying  whether  public  network  access  is  allowed  or  not  for  each 
address  pair. 

•  A  set  of  audit  generation  options  for  each  address  pair  that  is  allowed  to  have 
public  network  access. 

Any  authorization  based  on  IP  addresses  and  port  numbers  can  be  accomplished 
by  the  verification  of  GTGB  and  therefore,  can  be  replaced  with  AVT  checking  of 
GTGB  without  any  problem.  Needless  to  say,  the  GTGB  checking  is  more  restrictive 
in  the  sense  that  any  access  permission  by  lACG  can  be  denied  by  GTGB.  Therefore, 
it  would  be  a  good  idea  to  implement  local  access  control  policy  in  GTGB  tables  and 
let  it  do  the  authorization  service  for  PASS  scheme. 

Relocating  PASS  Components  on  GTGR 

Another  possible  move  with  GTGB  is  to  try  to  use  it  as  a  component  of  PASS 
scheme.  In  other  words,  it  is  tempting  to  implement  one  or  more  of  PASS  components 


130 


(e.g.,  Certification  Authority  or  Internetwork  Access  Control  Gateway  functions)  in 
GTGB  and  make  them  more  interactive. 

However,  it  is  not  realistically  possible  to  make  changes  on  GTGB  to  make  it 
useful  with  PASS  for  the  following  reasons: 

•  First,  current  version  of  GTGB  does  not  have  router  functionality.  Since  essen- 
tially aa  lACG  is  a  border  router,  we  cannot  use  GTGB  as  an  lACG.  Not  only 
this  but  for  the  following  reason,  does  it  not  a  good  approach. 

•  Second,  GTGB  is  designed  to  work  transparently  to  the  local  host  and  no  end- 
system  can  explicitly  request/receive  services  to/from  GTGB.  For  this  reason, 
it  cannot  be  used  as  a  Certification  Authority  for  PASS  scheme. 

•  Lastly,  it  is  extremely  difficult  to  modify  some  portion  of  GTGB  or  to  add  new 
services  into  it  because  of  the  security  requirement.  This  fact  also  discourage 
the  move  of  using  it  as  a  part  of  PASS. 


APPENDIX  B 
ACRONYMS 


ACL 

Access  Control  List 

ACS 

Access  Control  Server 

AD 

Administrative  Domain 

BAN 

Burrows,  Abadi,  and  JNeednam 

BGP 

Border  Gateway  Protocol 

CA 

Certincation  Authority 

DARPA 

Detense  Advanced  Research  Projects  Agency 

DCE 

Distributed  Computing  Environment 

DBS 

Data  Encryption  standard 

EGP 

Exterior  Gateway  Protocol 

GTGB 

Gemini  i  rusted  Guard  Base 

lACG 

Internet  Access  Control  Gateway 

ICMP 

Internet  Control  Message  Protocol 

IDPR 

Inter- Domain  Policy  Routing 

IETF 

Internet  Engineering  Task  Force 

IP 

Internet  Protocol 

ISO 

International  Standardization  Organization 

ITU 

International  Telecommunications  Union 

MD5 

Message  Digest  5 

MTU 

Maximum  Transmission  Unit 

OSI 

Open  System  Interconnection 

OSF 

Open  Software  Foundation 

PAC 

Packet  Authentication  Code 

PASS 

Packet-level  Access  Security  Scheme 

PG 

Policy  Gateway 

PR 

Policy  Route 

PT 

Policy  Term 

RPC 

Remote  Procedure  Call 

RS 

Route  Server 

TCP 

Transmission  Control  Protocol 
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